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

Sync: re-factor error handling #887

Open
3 tasks
rfc2822 opened this issue Jul 4, 2024 · 2 comments
Open
3 tasks

Sync: re-factor error handling #887

rfc2822 opened this issue Jul 4, 2024 · 2 comments
Labels
refactoring Internal improvement of existing functions

Comments

@rfc2822
Copy link
Member

rfc2822 commented Jul 4, 2024

Currently, handling of sync errors is scattered between various locations:

  • Sync worker throws and handles some errors and show notifications for some other errors
  • Syncer throws errors (for instance when the content provider is not available, after Remove address books sync authority and content provider #877) and handles others (SecurityException, DeadObjectException)
  • SyncManager throws and handles other errors (per collection)

We should

  • clearly define which component is responsible for throwing which error,
  • define which component is responsible for handling which error in which way (notification, instant/with retries, …)
  • show a notification when the content provider can't be acquired at sync during to missing permissions or other reasons (see Remove address books sync authority and content provider #877 (review))

and refactor accordingly.

Maybe have a separate (injectable) error manager that does notifications and for instance can also group errors of various collections? But that could also be a new issue.

Depends on #877. See also #886 – it probably makes sense to think about error handling when defining the sync result data type.

Depends on #896

@rfc2822 rfc2822 added the refactoring Internal improvement of existing functions label Jul 4, 2024
@rfc2822 rfc2822 changed the title Sync: clearly define which component is responsible for which error Sync: re-factor error handling Jul 4, 2024
@rfc2822 rfc2822 mentioned this issue Jul 11, 2024
6 tasks
@sunkup sunkup mentioned this issue Jul 30, 2024
4 tasks
@github-actions github-actions bot removed the dependent label Aug 5, 2024
Copy link

github-actions bot commented Aug 5, 2024

@rfc2822
Copy link
Member Author

rfc2822 commented Sep 16, 2024

If a collection has 404: show a message that refreshing the service list may help.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
refactoring Internal improvement of existing functions
Projects
None yet
Development

No branches or pull requests

1 participant