rosemarYuan commented on issue #841: URL: https://github.com/apache/flink-agents/issues/841#issuecomment-4904591952
Thanks @addu390, happy to take this up after I wrap up the current Memory observability work. I’ll keep the first PR scoped to recording-only and share the design/implementation for review. Agreed on the split for @zxs1633079383: - `eventId`: the concrete event id, preserving current event identity semantics. - `runId`: a replay-stable run identity derived from stable runtime coordinates. - `sourceEventId` / `emittingAction`: the causal edge from the processed event to the event emitted by an action. One small addition I think would help reconstruction: - `emitIndex`: the ordinal of an emitted event within the parent action invocation. The reason is that `sourceEventId + emittingAction` identifies which action invocation emitted an event, but it does not order multiple sibling events emitted by that same invocation. Recording `emitIndex` makes the sibling order explicit, instead of relying on log layout. This is useful because: - Python generator/async actions can drain emitted events across multiple polls. - Per-subtask event-log files may later be merged, where cross-file line order is not a strong contract. - `(sourceEventId, emittingAction, emitIndex)` gives v1 a stable emitted-event occurrence key and leaves a clean path for a later deterministic event-address scheme. I would define `emitIndex` as the ordinal within the parent action invocation, rather than just the local batch index.@zxs1633079383 thanks for the field shape, would welcome your review -- 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]
