Goals

• No annoying error bars for recoverable errors (e.g. network), especially a requirement for Instant Sync
• No annoying error bars for recurring errors that have already been acknowledged but can't be solved without a software update
• No annoying error bars during planned server maintenance windows.
• Be more informative about problems when an error occurs ("Unknown Error" is not very helpful and doesn't help when users report bugs).

Proposal

• Network errors should NEVER escalate bug 659067
  • ensure that all network failures actually end up setting the right bits here, cf bug 624436
  • Instead warn user if they haven't synced successfully for a while (e.g. a week).
  • Learn from Fennec's update handler? bug 618316
• Def.: "Syncing successfully" = syncing without any *new* errors (errors that we've reported in the past should not resurface)
• Operations must be able to send a response that does not escalate for some time
  • ops uses 503+retry-after to indicate "work underway" which escalates immediately, 100% of the time, and is thus a poor solution for planned maintenance events
  • bug 578195 contains prior discussion about this, requirements here override anything ops stated in bug
• Kill Unknown Error
  • Mention which engine the error occurred in bug 675125, bug 675130
  • If we know, mention what part of process the error occurred in (download, upload, etc.)
  • Whereever we throw, throw a meaningful value that can be turned into an l10n

Implementation

• Suggestion: rip out error handling from Service, implement Error Handler Policy that tracks errors (some of them persistently) and escalates them to UI when necessary