wenjin272 opened a new issue, #1084: URL: https://github.com/apache/flink-agents/issues/1084
### Search before asking - [x] I searched in the [issues](https://github.com/apache/flink-agents/issues) and found nothing similar. ### Description `ActionStateUtil.generateUUIDForEvent()` currently derives the event component of a durable action-state key only from `event.getAttributes()`. It does not distinguish separate event occurrences whose attributes are identical. When two distinct events reach the same action under the same business key and sequence number, identical attributes produce the same action-state key. After the first event completes, the second lookup can return the first event's completed state, skip the second execution, and replay the first output instead. This issue predates event attachments and can occur with any two events that have identical attributes. However, event attachments make it easier to encounter because different payloads may be carried entirely in attachments while the attributes remain identical. The key needs to distinguish event occurrences within a run while remaining deterministic across source replay. Using `Event.getId()` directly is insufficient because replaying an input record creates a new random event ID. A deterministic occurrence identity, such as a replay-stable ordinal or lineage path, may be needed. This was identified and discussed while reviewing #950: https://github.com/apache/flink-agents/pull/950#discussion_r3732939312 ### How to reproduce 1. Enable a durable action-state store. 2. From one action, send two events of the same type to the same downstream action. Keep their attributes identical but give them different attachment payloads: ```java Event first = new Event("WorkItem"); first.setAttachment("payload", "item-1"); ctx.sendEvent(first); Event second = new Event("WorkItem"); second.setAttachment("payload", "item-2"); ctx.sendEvent(second); ``` 3. Let the downstream action complete the first event before the second state lookup. Expected: the downstream action runs once for each event and produces distinct results for `item-1` and `item-2`. Actual: both events generate the same durable action-state key. The second execution can be skipped and the result from `item-1` replayed for `item-2`. A regression test can be added to `ActionExecutionOperatorTest` using an invocation counter and an `InMemoryActionStateStore` to verify that both sibling events are executed. ### Version and environment Current `main` (`0.4-SNAPSHOT`). The issue affects the Java runtime when durable execution is enabled, independent of the specific durable store backend. ### Are you willing to submit a PR? - [ ] I'm willing to submit a PR! -- 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]
