Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Surface DecodingError.Context in UI or in Crashlytics #709

Open
ualch9 opened this issue Jan 10, 2024 · 0 comments
Open

Surface DecodingError.Context in UI or in Crashlytics #709

ualch9 opened this issue Jan 10, 2024 · 0 comments

Comments

@ualch9
Copy link
Member

ualch9 commented Jan 10, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant