Extended forward-compatibility in client

[jakubfijalkowski]

Now, the client ignores new fields (which is good!) but we might add another rule: if the field gets removed (i.e. it is not in the payload), try to assign default value if it is primitive type. Removing field would still be a breaking change, but client will be less prone to them and will not throw on deserialization.

[shilangyu]

I understand the premise of this request however I have a few issues with it:

1. It would be a very local solution (works only with primitive types)
2. Would add quite a bit of noise to generated contracts (JsonKey above every [primitive] field. This might seem cosmetic but after all mobile devs read the generated contracts quite often)
3. Hides problems. For example say that a non-nullable field is returned as null (not because it was removed, just because its a backend bug), on mobile it will default to some arbitrary value hiding the existence of the bug.

Ad 1. technically any contract type could have a default created (since all of them are in the end created using KnownTypes) but this would contribute even more to Ad 2.

Ad 3. afaik package:json_serializable gives no option to distinguish the lack of a field and a field just being null

Personally Ad 1. hurts me the most, I don't like partial solutions, I understand this is an idealistic and non-realistic approach, but it would be nice if we can solve this problem more universally

[jakubfijalkowski]

It would be a very local solution (works only with primitive types)

Indeed it will be, but for some features "playing safe" is better than being fully correct.

Would add quite a bit of noise to generated contracts (JsonKey above every [primitive] field. This might seem cosmetic but after all mobile devs read the generated contracts quite often)

This I agree with. The contracts should stay clean.

Hides problems.

It should not hide the problem - it only should make the app more resilient (meaning - the app should notify developers that something bad happened, but should try to provide functionality either way).

it would be nice if we can solve this problem more universally

I don't think that is possible. This issue mostly reflects a real-world situation - someone made a mistake and deployed new app to production. We don't want users to notice this.