You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@flink.apache.org by "Jackeyzhe (via GitHub)" <gi...@apache.org> on 2026/07/07 15:36:12 UTC
Re: [PR] [FLINK-39962] [runtime] Fix flaky DeclarativeSlotPoolBridgeTest [flink]
Jackeyzhe commented on code in PR #28535:
URL: https://github.com/apache/flink/pull/28535#discussion_r3537746634
##########
flink-runtime/src/test/java/org/apache/flink/runtime/jobmaster/slotpool/DeclarativeSlotPoolBridgeTest.java:
##########
@@ -224,8 +231,15 @@ void testNoConcurrentModificationWhenSuspendingAndReleasingSlot() throws Excepti
@TestTemplate
void testAcceptingOfferedSlotsWithoutResourceManagerConnected() throws Exception {
+ final ManuallyTriggeredScheduledExecutorService scheduledExecutor =
Review Comment:
I checked the production path around DeclarativeSlotPoolBridge. I do not think this race can occur in the main code in the same way.
The failing window requires pendingRequests to be mutated while the close path is copying/failing it. In production, slot-pool operations and scheduled callbacks are expected to be serialized through ComponentMainThreadExecutor. The copy-then-clear in cancelPendingRequests() then protects the later fail-request loop from reentrant modifications after the snapshot is created.
So this looks like a test-only flakiness caused by relying on real scheduled timing while closing the bridge from the test thread. Using ManuallyTriggeredScheduledExecutorService here looks reasonable to me.
--
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: issues-unsubscribe@flink.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org