slachiewicz commented on PR #285:
URL: 
https://github.com/apache/flink-connector-kafka/pull/285#issuecomment-5600809629

   @Efrat19 Yes, that is exactly what happened.
   
   ### Root Cause Analysis
   In `MockSplitEnumeratorContext`, `getSentSourceEvent()` is implemented by 
submitting a task to `workerExecutor`:
   ```java
   workerExecutor.submit(() -> new HashMap<>(sentSourceEvent)).get();
   ```
   `workerExecutor` is a single-threaded executor.
   
   In 
`DynamicKafkaSourceEnumeratorTest#testProductionMetadataRefreshBypassesBlockedSourceCoordinatorAsyncCallable`,
 the test deliberately blocks `workerExecutor` with an async callable waiting 
on a `CountDownLatch` (`allowSourceCoordinatorCallableToFinish`), specifically 
to assert that metadata discovery bypasses a blocked coordinator callable.
   
   When `hasLatestMetadataUpdateEvent()` called `context.getSentSourceEvent()`, 
it queued onto the blocked `workerExecutor` and waited indefinitely on 
`FutureTask.get()`, causing the 50-minute CI timeout.
   
   ### Resolution
   In `5df47434`:
   - Retained reflection via `Whitebox.getInternalState(context, 
"sentSourceEvent")` in `getLatestMetadataUpdateEventWithoutContextSync()` with 
an explanatory comment documenting why `getSentSourceEvent()` deadlocks here.
   - Kept the `catch (AssertionError | ConcurrentModificationException e)` in 
`hasLatestMetadataUpdateEvent()` so concurrent modifications during polling 
retry cleanly.
   
   Verified locally: 
`testProductionMetadataRefreshBypassesBlockedSourceCoordinatorAsyncCallable` 
now completes in ~17 seconds without hanging.


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