You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 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.The text was updated successfully, but these errors were encountered: