Third party apps wouldn't fail if they were correct in the first place. Failing gracefully on unexpected input is the way a competent engineer would structure their program.

Is there a functional difference between "my production code suddenly stopped processing work because it rejected a newly nullable input value" vs "my production code suddenly stopped processing work because it crashed on a newly nullable input value"?

If the crash gives an attack vector for a security threat then there is.

Personally, "Be conservative in what you do, be liberal in what you accept from others" is a bad policy in the modern world. It should be "Be conservative in what you do, be strict as if you don't trust them in what you accept from others".

That's a valid point if it's security-critical. My initial response was with regards to grandparent comments arguing over semantics, when the end results in both cases was "successful processing ceased because of an API change."

'Liberal in what you accept from others' in this case would mean being prepared to handle nullable JSON fields.

Ideally it's more like "my production code skipped over 1% of batch jobs because it didn't expect the null values" or something like that. Handling errors gracefully is a bit of an art unto itself.

Indeed it is an art.

production code that rejects a suddenly nullable input value is more deterministic than "something crashed" and can be handled better (triggering a watchkeeper, notification) rather than relying on someone paying attention to the crash logs.

"Failing gracefully" is still failing. I don't want my app to fail, gracefully or otherwise.