Bug 29563

Summary: account storage plugins should have commit_async()
Product: Telepathy Reporter: Will Thompson <will>
Component: mission-controlAssignee: Telepathy bugs list <telepathy-bugs>
Status: RESOLVED MOVED QA Contact: Telepathy bugs list <telepathy-bugs>
Severity: normal    
Priority: medium    
Version: git master   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Bug Depends on: 54873    
Bug Blocks:    

Description Will Thompson 2010-08-13 09:33:53 UTC 
So. I found a note on an old TODO list saying that UpdateParameters() may return before the changes are written to disk. I don't think this is *that* big a deal, though it'd be nice to be sure. So I thought I'd check.

It turns out that update_parameters_dup_params_cb() — which is the last step in the UpdateParameters() implementation — calls mcd_account_manager_write_conf_async(), but then immediately calls tp_svc_account_return_from_update_parameters() without waiting for write_conf_async() to call the callback (which is NULL in any case). Horror of horrors!

But actually... mcd_account_manager_write_conf_async() synchronously tells each backend to commit. And the commit() implementation for the keyfile backend is synchronous. So the implementation is correct by accident.

The commit() implementation for accounts-glib, on the other hand, is asynchronous. But since the commit() API doesn't allow returning asynchronously, it always returns success, and just logs a debug message if the changes weren't committed. So the plugin API is at fault here.
Comment 1 Simon McVittie 2012-09-13 15:22:59 UTC 
This would be great in principle, but the necessary yak-shaving to get there is quite extensive. My recent series of storage-refactoring branches go some way towards it, by having a mock account-storage backend that could actually test this... but McdAccount will also need considerable work.
Comment 2 GitLab Migration User 2019-12-03 19:34:48 UTC 
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-mission-control/issues/31.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.