Arvados

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 using self.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.