The way we clean up the session data and complete the operation is broken. It is particularly bad when the _sync API is used.

The user's callback will be invoked before the clean up function because g_simple_async_result_complete_in_idle uses a higher priority than g_idle_add - G_PRIORITY_DEFAULT vs. G_PRIORITY_DEFAULT_IDLE. The _sync API uses a callback that quits the main loop and pops the thread context, and if there is no main loop running for the default context then the clean up will never occur.

This brings us to the next problem. Using g_idle_add sets up the clean up to occur on the default context, while the SoupSession was created to work with the current thread context. This is bad and occasionally leads to a deadlock when destroying the session.

PS: If you are wondering why we do the clean in an idle, then look at these commits:

commit 07f13b1d773b79e5c1049660c154b988b5ff6357
Author: Debarshi Ray <debarshir@gnome.org>
Date:   Wed Dec 5 16:03:01 2012 +0100

    ewsclient: Fix cancellation
    
    Free the AutodiscoverData in an idle handler because soup_session_abort
    invokes ews_client_autodiscover_response_cb. Trying to disconnect the
    GCancellable from a 'cancelled' signal handler will result in a
    deadlock.
    
    Fixes: https://bugzilla.gnome.org/689642

commit b2f94098829232bcb8294d5cefee85d5b9368f2d
Author: Debarshi Ray <debarshir@gnome.org>
Date:   Tue Dec 4 17:46:17 2012 +0100

    httpclient: Fix cancellation
    
    Free the CheckData in an idle handler because soup_session_abort
    invokes http_client_check_response_cb. Trying to disconnect the
    GCancellable from a 'cancelled' signal handler will result in a
    deadlock.
    
    Fixes: https://bugzilla.gnome.org/689642