The test hung in https://ci.chromium.org/buildbot/chromium.fyi/Fuchsia%20(dbg)/16894 while waiting for one of the two expected messages.

The test base pages use of base::RunLoop::QuitCurrentWhenIdleDeprecated(), so in principle if two IPC messages were delivered to the main message-loop while it was not scheduled then it could conceivably enter RunLoop::Run(), process both "quit" operations and leave a second Run() "hung", never exiting.

However, looking at the test itself, there is a simple lock-step of Send->ExpectMessage->Send->ExpectMessage, which means we shouldn't be able to get into a double-quitted state.

This flake was on Fuchsia, where we believe that the ChromeIPC+Mojo+Zircon stack can lose IPC messages on process-exit, so this may be a different example of the same underlying issue.