-
-
Notifications
You must be signed in to change notification settings - Fork 356
Calendar API error handling #2374
Description
Discuss your ideas or share your views:
I was thinking a little more about the conversation I had with @gikf in #2292 (comment) and the changes in #2354
It seems there are three concerns, in rough order of importance
- Error handling, particularly rate limits Google Calendar rate limits #2373
- Communicating to the user when they need to (re)authenticate and when the service is not available
- Avoiding useless requests to external APIs
1 and 2 are quite tightly coupled, since some errors will be caused by a lack of authentication.
3. can matter, since extra requests are wasteful and could push us over rate-limits. However, 1. and 2. seem crucial because otherwise the app could be broken and not give any sign to users.
With that in mind, it makes sense to set up the error handling + communication about those errors to the user first.
The key thing is that whatever we do needs to keep #2373 in mind, since rate limits seem to be the most likely source of errors.
Sorry this is a little nebulous: I wanted to make sure the decision making happened publicly and I have not refined my thinking about this yet.