DanielLeens commented on issue #11735: URL: https://github.com/apache/seatunnel/issues/11735#issuecomment-5814907923
Classification: D / Zeta bounded task-failure-history design.\n\nThanks for the detailed revision. I rechecked the current dev paths and the updated draft #11734. The important compatibility direction is preserved: pipelineRestoreNum is incremented by prepareRestorePipeline and is read by canRestorePipeline to enforce job.retry.times, while TaskExecutionState and TaskDeployState currently declare no serialVersionUID. Keeping diagnostics separate from that retry counter remains the right boundary.\n\nThe draft is substantially clearer, but it should remain a design draft until three details are made mechanically precise:\n\n1. The CREATED-timestamp attempt key needs an exact source-of-truth and handoff rule. SubPlan initially seeds INITIALIZING from its constructor timestamp, while later state timestamps are written before the state IMap transition. State which value is copied at reset/deploy, which master owns its monotonic update, and how a stale or duplicate report resolves with out relying on wall-clock coincidence.\n2. The queue ordering claim must cover overflow and retry exhaustion. A bounded offer may reject a capture, so terminal cleanup and restore cannot wait for the history write. State the observable result for a dropped record, and how finalization remains terminal-time fenced without claiming that every earlier record was persisted.\n3. Pinning the currently generated serial UIDs needs compatibility fixtures produced from the present wire form, plus forward/backward serialization tests before optional fields are added. Do not rely only on a serialver value in prose.\n\nPlease also name the exact non-map-store history maps and the cleanup owner/fence for each one, so that the stated persistence and bounded-retention guarantees can be tested. Once these are frozen in #11734, small implementation slices can be reviewed independently. No assignment or label change is made. -- 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]
