davidzollo opened a new pull request, #11642:
URL: https://github.com/apache/seatunnel/pull/11642

   ## Purpose
   
   `unit-test (11, windows-latest)` currently fails on every PR that has merged 
recent `dev`:
   
   ```
   [ERROR] 
MultiTableSinkWriterSchemaChangeBroadcastTest.schemaChangeKeepsIOExceptionContractWhenWorkerAlreadyFailed
   java.lang.RuntimeException: java.io.IOException: boom-before-schema-entry
   ```
   
   Observed on #11597, #11569, #11493, #11264 and #11203 — none of which touch 
multi-table sink code. The test arrived with #11015.
   
   ## Root Cause
   
   The test asserts the `IOException` contract of `applySchemaChange`, then 
calls `coordinator.close()` as unguarded teardown:
   
   ```java
   assertEquals("boom-before-schema-entry", schemaChangeFailure.getMessage());
   coordinator.close();   // <- no assertion, but any throw fails the test
   ```
   
   The worker failure it just asserted stays recorded. `close()` calls 
`checkQueueRemain()`, which only reaches `subSinkErrorCheck()` while 
`hasPendingRuntimeWrites()` is still true — so it rethrows the recorded failure 
exactly when the failing row has not been consumed yet.
   
   That is pure scheduling luck. Linux runners normally find the queue already 
empty and `close()` returns cleanly; the slower Windows runners still hold the 
row, hit the rethrow, and fail the test.
   
   ## Changes
   
   Tolerate either teardown outcome, and assert that any `close()` failure has 
the same root cause. A genuinely unrelated shutdown failure still breaks the 
test, so this narrows rather than loosens what teardown accepts.
   
   The contract assertions the test exists for are untouched.
   
   ## Note
   
   While tracing this, one inconsistency stood out but is deliberately left 
alone here: `MultiTableSinkWriter#close()` declares `throws IOException`, yet 
rethrows a recorded `IOException` as `throw new RuntimeException(firstE[0])`. 
Fixing that would change exception semantics on a path every multi-table sink 
job uses, which does not belong in a CI-stabilization change — flagging it for 
a maintainer's call.
   
   ## Does this PR introduce _any_ user-facing change?
   
   No. Test-only.
   
   ## How was this patch tested?
   
   The Windows unit-test job on this PR exercises the previously failing case 
directly.


-- 
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]

Reply via email to