DanielLeens commented on PR #11727: URL: https://github.com/apache/seatunnel/pull/11727#issuecomment-6368877597
I inspected the raw logs for the current Build linkage on head `a80834ebfb185ee0d54243e7a3ae99a5bf481817`: [run 35426701856](https://github.com/abdessalems/seatunnel/actions/runs/35426701856), attempt 1. The current failures are more specific than the earlier `SplitClusterFaultToleranceIT` explanation: | Failed job | Direct test failure in its log | | --- | --- | | [engine-v2-it / JDK 8](https://github.com/abdessalems/seatunnel/actions/runs/35426701856/job/105854144544) | `BackpressureSlowSinkIT.testCheckpointsKeepCompletingUnderSustainedBackpressure`: expected at least 3 additional completed checkpoints during 90s, observed 2; samples `[1,1,1,1,1,2,3,3,3]` | | [engine-v2-it / JDK 11](https://github.com/abdessalems/seatunnel/actions/runs/35426701856/job/105854144606) | Same backpressure failure, plus `CheckpointCoordinatorFailoverIT.testStreamJobFailsAfterCheckpointTriggerDispatchFailure`: expected `CHECKPOINT_INSIDE_ERROR`, received `Checkpoint notify complete failed` | | [all-connectors-it-2 / JDK 8](https://github.com/abdessalems/seatunnel/actions/runs/35426701856/job/105854144530) | `OpengaussCDCIT.testAddFieldWithRestore`: assertion timeout | | [all-connectors-it-2 / JDK 11](https://github.com/abdessalems/seatunnel/actions/runs/35426701856/job/105854144535) | Same OpenGauss restore assertion timeout | | [all-connectors-it-7 / JDK 11](https://github.com/abdessalems/seatunnel/actions/runs/35426701856/job/105854144377) | `PostgresCDCIT.testPostgresCdcSnapshotOnlyAndCommittedOffsetStartupModes`: expected one row, observed zero, then assertion timeout | The engine tests exercise checkpoint completion/failure semantics, so these logs alone do not establish an infrastructure-only failure or prove that #12311 resolves the current gate. They also do not establish that this PR introduced those failures. A baseline comparison or direct trace of those exact scenarios is still needed before assigning causality. I have preserved the assertions and have not issued another workflow retry. The safe next action is to diagnose the two engine failures against this exact head and its base, then obtain passing CI on the eventual contributor revision. This is a CI-evidence update, not a new approval or a claim that the PR is ready to merge. I also checked the concrete method names raised in the latest comment against this same fetched head: - [`BlockingWorker.run()` lines 1285–1294](https://github.com/apache/seatunnel/blob/a80834ebfb185ee0d54243e7a3ae99a5bf481817/seatunnel-engine/seatunnel-engine-server/src/main/java/org/apache/seatunnel/engine/server/TaskExecutionService.java#L1285-L1294) already reads `taskGroupExecutionTracker.context.getClassLoaders()`. It does not resolve the class loader from the shared location-keyed map. - There is no `finishOwnedResources()` method or its quoted monitor Javadoc in this version. [`finishExecution()` lines 1679–1701](https://github.com/apache/seatunnel/blob/a80834ebfb185ee0d54243e7a3ae99a5bf481817/seatunnel-engine/seatunnel-engine-server/src/main/java/org/apache/seatunnel/engine/server/TaskExecutionService.java#L1679-L1701) documents and performs a per-location `executionContexts.compute(...)` transition. - [`finishExecution()` lines 1703–1728](https://github.com/apache/seatunnel/blob/a80834ebfb185ee0d54243e7a3ae99a5bf481817/seatunnel-engine/seatunnel-engine-server/src/main/java/org/apache/seatunnel/engine/server/TaskExecutionService.java#L1703-L1728) removes `cancellationFutures` using this exact context and then recycles class loaders and cancels async/timer resources for that context, including the stale-generation branch. These calls are outside a service-wide `synchronized` block. - The test's explicitly limited deploy-return contract and separate redeploy race boundary are written at [lines 65–85](https://github.com/apache/seatunnel/blob/a80834ebfb185ee0d54243e7a3ae99a5bf481817/seatunnel-engine/seatunnel-engine-server/src/test/java/org/apache/seatunnel/engine/server/TaskDeployStaleContextRaceTest.java#L65-L85). That statement is a coverage boundary, not proof of the checkpoint CI scenarios above. These source pointers answer those specific stale-method/context-lookup assertions; they are not an assertion that every lifecycle question or CI gate has been resolved. <!-- daniel-fcp-repair-20261023-pr11727 --> -- 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]
