SEZ9 commented on issue #11735: URL: https://github.com/apache/seatunnel/issues/11735#issuecomment-5825610518
@goutamadwant thanks for checking each boundary against current `dev` (`7067a0984`) and syncing both copies in `e944f1e3`. Keeping the diagnostic attempt key separate from `pipelineRestoreNum` / `canRestorePipeline()` / `job.retry.times` remains the right boundary, and moving from "advance must complete before the restored execution starts" to reconciliation is the right call, since blocking restore on a diagnostic write would have changed restore availability. Three points still need to be written as mechanically precise rules rather than prose before implementation slices can be reviewed independently: 1. **Attempt key.** Please state exactly which value is copied at reset and at deploy time (constructor timestamp vs. the value written by `resetPipelineState()`), which master owns the `max(now, previousCreated + 1)` update, and how a stale or duplicate worker report resolves to a single attempt without relying on wall-clock coincidence between masters. Your bullets are the right shape; they just need the failure cases spelled out. 2. **Best-effort writes.** The bounded `offer` and the three-retry limit mean a capture can be dropped. Please state the observable result of a dropped record (what the history and the `/job-info` diagnostics show) and how finalization stays terminal-time fenced without claiming every earlier record was persisted. Terminal cleanup and restore must not wait on the queue. 3. **Wire compatibility.** For pinning the `TaskExecutionState` and `TaskDeployState` serial UIDs, please add compatibility fixtures generated from the present wire form plus forward/backward serialization tests before any optional field is introduced, rather than relying on the `serialver` values in the text alone. Please also name the exact non-map-store history maps and, for each one, the cleanup owner and its fence, so the persistence and bounded-retention claims are testable. Once those are frozen in the design text, I'm happy to review small implementation slices one at a time. No label or assignment change from my side yet. <!-- streview-comment:1293 --> -- 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]
