JeremyXin commented on PR #11841: URL: https://github.com/apache/seatunnel/pull/11841#issuecomment-5728580792
@DanielLeens Thanks for the detailed follow-up. I understand the concern about mixed-version submissions and agree that `JobImmutableInformation` should remain the authoritative source for restore decisions. At the same time, if `CoordinatorService.submitJob` derives the savepoint flag from `JobImmutableInformation`, the `isStartWithSavePoint` parameter becomes unused for the method’s business logic. Trying to use both values by comparing them and handling mismatches would introduce two restore decisions and make the submission flow more confusing. So I see two consistent choices: 1. Keep Option 1: retain `isStartWithSavePoint` for wire compatibility, have current callers derive it from `JobImmutableInformation`, and let `CoordinatorService` use the caller-supplied value. 2. Adopt Option 2: remove `isStartWithSavePoint` from `submitJob(...)` and clean up the related `SubmitJobOperation` and client protocol path, with an appropriate compatibility/deprecation strategy. Given the mixed-version concern and the fact that the legacy parameter is otherwise no longer meaningful inside `CoordinatorService`, would you recommend that we adopt Option 2 directly, or should we keep Option 1 in this PR and explicitly defer the wire-level removal to a follow-up compatibility change? I would prefer not to keep two competing restore-decision paths in the same method. -- 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]
