[Bug 79827] MC crashes when GOA is restarted

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=79827

--- Comment #4 from Simon McVittie <simon.mcvittie at collabora.co.uk> ---
(In reply to comment #3)
> - mcd_account_delete_async() uses a GTask internally; it doesn't really need
> it as all its work in sync but it's a convenient object to report error or
> success to the user callback.

It is an API convention that async functions should always return in an async
way, even if their implementation could have been sync: callers should be able
to say "this will happen synchronously" or "this will take time" but never
"this will happen sync or async depending on implementation and I can't tell
which".

Deleting accounts calls out to a potentially-external backend, so it can
(conceptually) take time, so it is always async (even if the GOA backend is in
fact blocking).

> We could solve the first problem by not updating the Account.Enabled
> property of the account when deleting it. Does it really make sense to
> update it for an account which is about to disappear anyway?

I believe the idea was:

* if the account cannot be deleted, we do the closest thing we can

* disabling the account has side-effects, like taking it offline and
  cancelling its channel requests, and we want those to happen
  regardless

> Another option could be to unregister the Account D-Bus object earlier in
> the deletion process to avoid such tricky issues.

I feel as though this:

> (process:13703): mcd-DEBUG: mcd_account_delete: Forcing Account.Removed for
> gabble/jabber/goa_facebook_account_1377685019

ought to be the point at which the account is unregistered: that's the point at
which we have "officially" removed it. Does that actually take place?

When this code was written, dbus-glib had a bug (well, major feature omission):
objects could only be removed from the bus via last-unref. We fixed that: you
can now unregister objects explicitly. Our daemons should behave accordingly.

> (process:13703): mc-plugins-DEBUG: account-storage.c:907: default-gkeyfile:
> called for gabble/jabber/goa_facebook_account_1377685019

If this debug message logged the function name instead of the file+line, it
would make a lot more sense. I can't tell which is "added" and which is
"removed". The debug messages seem to have been written with the assumption
that DEBUG() would log the function name.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.