state uploads and session matching#147
Conversation
mattklein123
commented
Apr 30, 2026
mattklein123
commented
- Add handshake and mid-mux state uploads of unique entity ID as well as started sessions.
- Add ability for workflows to match on a session being started.
1) Add handshake and mid-mux state uploads of unique entity ID as well as started sessions. 2) Add ability for workflows to match on a session being started. Signed-off-by: Matt Klein <mklein@bitdrift.io>
| RuleLogMatch rule_log_match = 1; | ||
| RuleStateChangeMatch rule_state_change_match = 3; | ||
| // This will match when a new session starts. | ||
| bool on_new_session = 4; |
There was a problem hiding this comment.
I thought about using RuleStateChangeMatch for this but it doesn't really fit cleanly and IMO it makes more sense to keep this independent but let me know if you think otherwise.
There was a problem hiding this comment.
I think this makes sense in general since using RuleStateChangeMatch would expose the actual session ID for matching which I think adds more complexity than is necessary
| message OpaqueEntityUpdate { | ||
| // If one has been supplied, the opaque entity ID. If an update is sent that nulls this out | ||
| // it means that the unique entity is no longer bound (for example after a logout). | ||
| optional string opaque_entity_id = 1; |
There was a problem hiding this comment.
so during offline reconnect we'd just be sending the latest value of this? any reason we'd want to be able to see all changes or do we think that it's low frequency enough that this doesn't matter?
There was a problem hiding this comment.
I suppose I could make this keep track of all changes as I'm going to do with sessions it just seems like an extreme edge case. I will discuss with @Reflejo
There was a problem hiding this comment.
Per offline convo for now we will just send the most recent one. We are going to store entity changes in state though which should make changes visible in timeline once we finish that work.
| RuleLogMatch rule_log_match = 1; | ||
| RuleStateChangeMatch rule_state_change_match = 3; | ||
| // This will match when a new session starts. | ||
| bool on_new_session = 4; |
There was a problem hiding this comment.
I think this makes sense in general since using RuleStateChangeMatch would expose the actual session ID for matching which I think adds more complexity than is necessary
2 participants
