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.
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.
-- 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.