DanielLeens commented on issue #11735: URL: https://github.com/apache/seatunnel/issues/11735#issuecomment-5832133061
Classification: D / Zeta bounded task-failure-history design. Thanks for converting the open points into R1-R5 and for splitting the wire-form guard into #12466. I rechecked the current `dev` paths: `pipelineRestoreNum` is incremented in `prepareRestorePipeline()` and read by `canRestorePipeline()` for retry eligibility, while `resetPipelineState()` currently rewrites the `CREATED` timestamp before changing the pipeline state. Keeping diagnostic identity separate from that counter remains mandatory. The revised STIP now makes the critical design boundaries reviewable: R1 distinguishes the `CREATED` key from `INITIALIZING` and names the reset/deploy writers; R2 defines stale-report resolution; R3 states the observable result of a rejected or exhausted best-effort operation without claiming complete history; and R4 names both non-map-store maps, their owner fences, terminal-time expiry, and cleanup ownership. The next implementation slice must preserve those rules with the acceptance tests, especially write-retry monotonicity, active-master handoff, queue rejection, terminal cleanup, and the known-empty versus unknown REST distinction. #12466 is correctly limited to pinning the two existing serial UIDs and testing reads and writes against historical bytes; it adds no optional field. However, its Build is currently failed and the PR is BLOCKED, so neither that slice nor the wider design is ready to advance. Please first identify and resolve or document the failing CI result on that exact head. When fields are added later, retain these fixtures and add both old-bytes/new-class and new-bytes/unmodified-class-loader tests. #11735 remains the canonical STIP record, with #11734 retained only as the draft design reference. Keep the failure-history implementation in independent slices after the contract and CI gates are satisfied; do not combine it with retry-policy or restore-scheduling changes. -- 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]
