Idea #21257
openarvados.events last_log_id handling seems sus
Description
The API for both clients in arvados.events
presents last_log_id
like it's specific to an event stream. Any time you subscribe to an event filter, you can also pass in a last_log_id
.
However, internally, that value gets flattened into a single instance last_log_id
. Which makes sense, because as far as I know there's no way for the WebSocket client to know which subscription caused an event to be sent to it.
However, consider the following chain of events:
- You start an
EventClient
with an explicit filter and get at least one event for it.self.last_log_id
is the id of the last event. - You subscribe to another filter with an explicit
last_log_id
that's earlier than the current value and get at least one historical event for it.self.last_log_id
is the id of the last event, and lower than it was in the previous step. - A network error causes a WebSocket connection error.
EventClient
reconnects and resubscribes to all your filters usingself.last_log_id
. Because that is lower than events from the first subscription,EventClient
will receive and re-handle the events that it already handled from the first subscription, and maybe even earlier ones.
If we want to support multiple event streams, I think we need support from the WebSocket server to do that. Then once we have that, EventClient
needs to take proper advantage of it.
If we don't want to add proper support, then IMO EventClient
should ignore the last_log_id
argument of subscribe
, maybe with an explicit warning if the user passes in a real value.
No data to display