Fault tolerance
Today’s 0.7.9 release improves the user experience when the local or remote addressbooks fail in unexpected ways.
For the technically curious, here’s a behind-the-scenes look at addressbook failures.
Example 1 - Google permanent failure
The Google Contact API enforces a uniqueness rule when contacts are created, but not when they are retrieved. So when a Google account contains duplicates (and this does happen), the client gets a set of contacts that it can’t reliably edit.
Aside from leaving the client in an awkward spot, this behaviour is the opposite of Jon Postel’s Robustness Principle, commonly paraphrased from rfc 793 as:
be conservative in what you send, be liberal in what you receive
Example 2 - Google transient failure
The Google Contact API allows 71 of 83 contacts to be created then for #72 reports:
Internal exception
Error 401
Example 3 - Thunderbird transient failure
A remote contact gets deleted but Thunderbird refuses to delete it’s local counterpart:
Component returned failure code: 0×80004003 (NS_ERROR_INVALID_POINTER) [nsIAbDirectory.deleteCards]
Fault tolerance
The Zindus addon is designed to work in a sync mesh and failures at every node in the mesh are inevitable. When a failure is detected, the sync engine has a choice:
- give up persistence ==> back out changes made in the local+remote addressbooks
- give up convergence ==> addressbooks are out of sync. This is what the Zindus addon does.
The Thunderbird statusbar indicates when the addressbook is out of sync.
Most failures are transient and generally don’t require user intervention. On the next sync, the sync engine picks up from where it left off. In example 2 above, the engine tries to create contact #72 and in example 3, delete the appropriate contact.
When a failure is permanent, the status indicator remains ‘X’ until the user intervenes to fix it.
Fault tolerance isn’t an exciting subject, but it’s a key ingredient in delivering a reliable and unobtrusive contact sync service to Thunderbird users.
If you liked this Blog, share the love :
Follow on twitter
RSS Feed
August 20th, 2008 at 2:35 am
Example 3 indicates a bug of some sort. If the extension is passing null into nsIAbDirectory.deleteCards, the bug is in the extension, otherwise the bug is in Thunderbird. If there is a Tb bug here, it would be great if you could file a bug in Bugzilla with more details.
August 20th, 2008 at 1:25 pm
Dan -
As suggested, a bug report has been filed against example #3:
https://bugzilla.mozilla.org/show_bug.cgi?id=451306
Here are references to the discussion of each of these issues on the relevant developers lists:
example #1 - Google duplicates:
http://groups.google.com/group/google-contacts-api/browse_thread/thread/1e745c13924ffc34/
example #2 - Google Internal exception:
http://groups.google.com/group/google-contacts-api/browse_thread/thread/2887f1c7314cc646
example #3 - Thunderbird deleteCards:
http://groups.google.com/group/mozilla.dev.apps.thunderbird/browse_thread/thread/8100b8dd0d6becce
May 11th, 2009 at 12:32 am
Your site displays incorrectly in Firefox, but content excellent! Thank you for your wise words:)
May 25th, 2009 at 9:35 am
@Jessica - yes, the css is messy. There’s a plan to fix it (this year). And thanks!
February 23rd, 2010 at 4:29 am
What are we supposed to do on status “X” sync failed?
I see no log or reporting mechanism to deal with this?
I’m sort of stuck with no sync on contacts and I’m not sure what to do next.
February 23rd, 2010 at 7:18 am
@Mark - to investigate the cause, visit Tools/Zindus and select ‘Sync Now’.
Without any data it’s premature to speculate but to hazard a wild guess: Google has recently become much more aggressive about invalidating authorization tokens. Version 0.8.15 will auto-recover from that situation, 0.8.14 and prior require manual intervention.
February 23rd, 2010 at 7:29 am
@leni - Thanks. It turned out that one of three passwords for the accounts listed was invalid. What is strange is that (perhaps because it was 1st) the other 2 accounts never synch’d due to the one account failing.
February 23rd, 2010 at 12:08 pm
@mark, yes in general the addon will fail fast, so if sync with the first account failed, it won’t try the others.
February 23rd, 2010 at 4:26 pm
@leni - Ok that’s fine, but if there is no visual reporting in the UI via a popup or something, you have no idea that:
1. Anything is even wrong
2. That you need to take action
3. Where you need to take that action
The X is no obvious, and lacking any error messaging I was out of sync for 2 weeks before noticing something was up.
February 23rd, 2010 at 4:42 pm
@mark - point taken. UI aims to be non-instrusive but perhaps it is erring on the side of discretion.
Will experiment with a colour indicator - eg red background behind ‘X’. Look for a change along these lines in the testing release once 0.8.15 is out.