Ashfaqbs commented on issue #1084: URL: https://github.com/apache/flink-agents/issues/1084#issuecomment-5658985854
Thanks @wenjin272, both points are correct and the original proposal as written doesn't survive either. **On (1):** this is a bug in the proposal, not the core idea. A yield/resume continuation (`ActionTaskResult#getGeneratedActionTask()`) is constructed with the *same* `event` and `action` as its predecessor, so it already resolves to the same durable-state key across its whole resume chain via `ActionStateUtil.generateKey(key, seqNum, action, event, ...)`. The ordinal should only ever be assigned when `createActionTask()` fires for a genuinely new (event, action) triggering, never when a continuation is re-enqueued. Scoped that way, a resumed task keeps its original ordinal automatically, because it never gets a new one to begin with. **On (2):** this one kills the "per-round enqueue counter" approach outright, not just the continuation edge case. The counter is a shared, order-dependent resource, and `actionState.isCompleted()` lets one sibling fast-replay instantly during recovery while another must actually redo its async wait — so two siblings racing for "next ordinal" can legitimately land in a different relative order than the original run. No amount of patching the counter's increment points fixes that; the foundation itself isn't replay-stable. Proposed alternative: stop deriving identity from *when* something gets enqueued and derive it from *where* it sits in the causal event tree instead. An internal event's position in its parent action's `outputEvents` list is fully determined by the parent's own business logic — same inputs, same output list, same order, every time, independent of scheduling or of how any sibling task happens to replay. So: identity = (parent's own already-deterministic state key, this event's index within that parent's output list), recursively grounded at the root `InputEvent`'s existing `seqNum`. Two siblings' identities never touch a shared mutable counter, so nothing about how fast one of them replays can perturb the other's key. Want me to work up a prototype against this (lineage-path) design before we settle on it, or does this need more discussion first? Happy to hold off on a PR until you've had a chance to poke holes in this one too. -- 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]
