We frequently have server-side data scheme changes that may cause a non-optional field to be missing (for example, #588 and #706). Currently, this causes the user to see an unhelpful "The data couldn't be read because it is missing." alert.
To triage, a developer needs to (1) attach to the app, (2) reproduce the unexpected response, (3) output the DecodingError object in the debugger, and finally (4) update the Swift Decodable model. This process is costly and may cause us to not catch other more serious errors immediately.
In particular, we are interested inDecodingError.Context, where it contains which key is missing/corrupted/type mismatched/etc. This should be shown in the UI where the error description text is shown, and/or uploaded to Crashlytics where we may proactively catch decoding errors.
We frequently have server-side data scheme changes that may cause a non-optional field to be missing (for example, #588 and #706). Currently, this causes the user to see an unhelpful "The data couldn't be read because it is missing." alert.
To triage, a developer needs to (1) attach to the app, (2) reproduce the unexpected response, (3) output the
DecodingErrorobject in the debugger, and finally (4) update the Swift Decodable model. This process is costly and may cause us to not catch other more serious errors immediately.In particular, we are interested in
DecodingError.Context, where it contains which key is missing/corrupted/type mismatched/etc. This should be shown in the UI where the error description text is shown, and/or uploaded to Crashlytics where we may proactively catch decoding errors.