873377 - social.reload-worker has a race issue with reloading sidebars

Status: RESOLVED WONTFIX

(Firefox Graveyard :: SocialAPI, defect)

Description

[edA-qa mort-ora-y]

I'm not sure that I can safely use the 'social.reload-worker' function without breaking any currently loaded sidebar. When the worker reloads all the connections with the sidebar are lost (the port is closed). To remedy this I thought I'd either reload the sidebars, or tell them to reconnect, but there is no appropriate order in which that can be done safely.

If I tell the sidebars to reload they will reload, but I can't control the order of that reload with respect to the worker reload. So I have no idea if they'll form an appropriate connection to the worker. The same thing happens if I merely send a message telling the sidebars to reload.

Now, the work also can't fix the problem since it can't discover workers. It relies on the initial connection messages to even know a sidebar exists. Thus when it reloads it has no knowledge of the existing sidebars.

As the 'social.reload-worker' is specified now I don't see any method by which I could alleviate potential race conditions. In my quick tests I happen to get the right loading order, but there's nothing guaranteeing that. It would be better if I 'reload' would actually restart the provider completely, including the sidebars.

Comment 1

[Shane Caraveo (:mixedpuppy)]

If you notify content areas to reload, then call social.reload-worker, you should be covered.  When any content area gets a port and sends a message, that message should be queued until the worker is loaded and starts handling connections.

Comment 2

[Shane Caraveo (:mixedpuppy)]

deprecation in fx51