Please sign in to comment.
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Avoid multiple "Monitor_connection_failure" dialogs
Summary: If we're not connected but the lockfile is present, then we'll try once a tick to reconnect. Normally this works in pretty short order. But sometimes (for reasons I don't know) the monitor gets stuck in a state where it just won't accept connections. The comments in serverMonitor suggest this is due to "DDOS" but I bet there are other circumstances. Anyway, let's take that behavior as given. There were two terrible user-consequences we observed: (1) It pops up a dialog reporting the error message "hh_server: Monitor_connection_failed" as desired. A second later, it attempts to connect again, and dismisses the dialog, and then pops up another dialog with the same information. And so on for ever. (2) Actually, due to a race condition, it didn't always dismiss the dialog. It only dismissed every other dialog. And so the dialogs kept piling up. This diff fixes both diffs. Bug (2) was due to the following race condition: 1. Imagine the previous error dialog was up; its handler's action (for when the user closes the dialog) is to clear the dialog flag in the Lost_server state 2. We call "do_lost_server". This calls "dismiss_ui" which sends a $/cancelRequest also clears the "dialog" field of Lost_env. Next it puts up an all new dialog in the "dialog" field, with its all new handler. 3. Nuclide handles $/cancelRequest and sends a response back to the server. This invokes the old handler. But the old handler's behavior was to clear out the "dialog" field, and even though that flag now belonged to the new dialog not the old one. This diff fixes the bug by making a handler only clear out the "dialog" field if it's the right one. The fix is actually implementation-specific, resting on the behavior of physical inequality (!=) of non-mutable things. It would be nice to write a proper fix. But I can't be bothered because it works, and because the fix for bug (1) renders this path unreachable. Bug (1) is addressed as explained by the following comment: (* If we already display a progress indicator, and call do_lost_server *) (* to display a progress indicator, then we won't do anything. Likewise, *) (* if we already display an error dialog with ANY TEXT and Restart button, *) (* and call do_lost_server to display any other text in the error dialog, *) (* it makes for a nicer UI to simply leave the old text up. *) Reviewed By: arxanas Differential Revision: D6804293 fbshipit-source-id: 662294f06f9b784349560b02d15903268ab10c38
- Loading branch information