wenjin272 commented on issue #1084: URL: https://github.com/apache/flink-agents/issues/1084#issuecomment-6493700397
Thanks for revisiting this. I think the lineage-based direction is reasonable. The identity rules could be expressed as: ```text Event occurrence ID = hash(parent action execution ID, output ordinal) Action execution ID = hash(triggering event occurrence ID, action identity) ``` The root event identity is scoped by the business key and input `seqNum`. These can be fixed-size hashes; we do not need to carry the full lineage path. Assign the occurrence ID at `sendEvent()`, preferably through runtime metadata or an internal envelope to preserve existing public APIs and `Event.id` semantics. Sending the same Event object twice should produce two distinct occurrences. Both ActionState keys and chat/internal-subagent call IDs should use this identity, covering the persistence-disabled collision discussed in #1220 as well. `generateKey()` should remain pure. For suspension and recovery: 1. **Yield/resume:** preserve the action execution ID and continue its output counter. Re-enqueuing or draining an output batch must not reset it. 2. **Completed-action replay:** reuse the occurrence IDs saved with the output events, without assigning new ordinals. 3. **Unfinished-action re-execution from the beginning:** retain the action execution ID and restart output numbering from zero, so corresponding outputs reproduce their identities. We already have content-based replay-divergence handling, and this change should preserve that protection. Lineage identifies an occurrence; content validation determines whether its previous state can be reused. If content is removed from the key derivation, equivalent validation must happen before reusing cached state. Please include recovery tests covering reversed sibling completion order, multiple output batches across yields, and re-execution of unfinished actions. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
