DanielLeens commented on PR #12311: URL: https://github.com/apache/seatunnel/pull/12311#issuecomment-6138731403
@SEZ9 Here are the exact pointers you requested against the current head `65ef1bde182`: - **F1 / job-status gate:** `CoordinatorService.resolveLostMemberState` at `CoordinatorService.java:2234-2249` returns `CANCELED` only when `JobStatus.CANCELING`; `CANCELING`, `DEPLOYING`, and `RUNNING` resolve to `FAILED` for every other or missing job status. The negative matrix is in `CoordinatorServiceLostMemberResolutionTest#engineInitiatedCancelStillResolvesToFailed` (`:81-91`) and `#deployingAndRunningVerticesStillResolveToFailed` (`:94-111`). - **F2 / siblings and locking:** `#notYetCancelledVerticesOfUserCancelledJobResolveToCanceled` is at `CoordinatorServiceLostMemberResolutionTest.java:63-73`. The production read, decision, and transition are all inside `synchronized (physicalVertex)` at `CoordinatorService.java:2153-2191`; the job status is read per vertex inside that monitor. - **F3 / node-offline observability:** the member-loss-completed cancel emits a WARN with task group, lost address, job status, previous state, and resolved state at `CoordinatorService.java:2168-2181`. - **F4 / restore rationale:** the resolver Javadoc at `CoordinatorService.java:2221-2227` explicitly names `SubPlan#getPipelineEndState`'s `FAILING` pipeline-state check as the reason a no-task-failure failing pipeline still ends `FAILED`. - **F5 / F6:** the private worker is named `resolveTasksOnLostMember` (`:2140`), the helper returns `Optional<ExecutionState>`, and its Javadoc documents `Optional.empty()` as “leave the vertex alone” (`:2229-2233`). The public `failedTaskOnMemberRemoved` Javadoc (`:2110-2118`) explicitly states that the method may resolve a vertex to `CANCELED` despite its historical name. - **F7 / IT guarantee:** `SplitClusterFaultToleranceIT.java:363-372` now covers both the already-`CANCELING` vertex and still-`RUNNING` siblings, while separately stating that engine-initiated cancellation remains `FAILED`. CI update: I retried only the failed `changes` job in fork run https://github.com/DanielLeens/seatunnel/actions/runs/37762860404 after confirming its prior failure was the Maven Wrapper 3.1.0 download receiving HTTP 404 and that the same URL now returns HTTP 200. Attempt 2 is currently in progress. No source change was needed for that CI failure; I will not represent the tests as passed until the rerun actually reaches and completes them. -- 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]
