Sometimes SSE events can happen too fast for the client to make sense of them because of other incomplete async work relating to earlier events.

E.g.

When new branches are added to a multi-branch job, events are fired in the following order:

1. CRUD create event for the branch job
2. Job build run queued
3. Job build run started
4. etc

Atm, the above sequence of events happens too fast for the UI. The CRUD create event is still being processed (getting the branch info and updating the redux store) when the build run queued/started events arrive.

When the build run queued/started events arrive, branch state update redux actions are triggered, but the redux store still knows nothing about the branch and so ignores it, causing the events to effectively be ignored.

We could rejig the action handlers and store events etc etc, handling things within the redux store, but I think it would be better to try fix this in a generic way if possible because this seems like a scenario that we'll hit again.

My current thinking is that we could tell an SSE listener instance to stop sending specific events for a period of time and play them later when told.

So, taking the above multi-branch job .... when we receive the CRUD create event, we tell the listener to stop sending events for that job for now .... we get the job info, update the redux store and then tell the listener to start sending the events again, at which point it would play all of the events that happened during the window where it was not forwarding the events. This way, the events happen in the client in an order in which it can make more sense of them.