[FLINK-40675][sql-gateway] Fix unstable SqlGatewayServiceITCase#testReleaseLockWhenFailedToSubmitOperation

[SEPURI-SAI-KRISHNA]

What is the purpose of the change

testReleaseLockWhenFailedToSubmitOperation fails on CI with a RejectedExecutionException at its final submitOperation. The first operation turns FINISHED on its pool thread, before that thread is back in the pool, and the pool hands work off through a SynchronousQueue. A submit right after awaitOperationTermination can therefore still find no free thread.

Brief change log

• Retry the final submit until the pool accepts it. Any other exception still fails the test.

Verifying this change

• With a delay injected after the first operation completes, the old test fails every time with the CI error, and the new test passes.
• With the lock release on rejection removed, the new test hangs as the old one did, so it still guards the lock.
• SqlGatewayServiceITCase passes.

Does this pull request potentially affect one of the following parts:

• Dependencies (does it add or upgrade a dependency): no
• The public API, i.e., is any changed class annotated with @Public(Evolving): no
• The serializers: no
• The runtime per-record code paths (performance sensitive): no
• Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: no
• The S3 file system connector: no

Documentation

• Does this pull request introduce a new feature? no

---

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)

Generated-by: Claude Code (Opus 5)

[flinkbot]

CI report:

• b925916 Azure: SUCCESS

Bot commands

The @flinkbot bot supports the following commands:

• @flinkbot run azure re-run the last Azure build

[MartijnVisser]

Changing a test to fix an instability is usually the wrong layer, so why this one is different. The test assumed a pool thread is free once an operation reports FINISHED. It never was: the status is set inside the task, before the worker is back on the SynchronousQueue, and the CI logs show 500 active threads at the moment of rejection. Nothing the pool exposes reliably says a worker will accept work, so the successful submit is the wait, not a loosened assertion. It does give something up. A rejection that is spurious rather than saturation now goes unnoticed for ten seconds. It still fails when it should: with the lock release on rejection removed it hangs, as the old one did. The table stage is green, the only failure is FLINK-40664 and is unrelated.

[MartijnVisser]

This message says the opposite of what a timeout here means. If it fires, the pool never freed a thread.

[SEPURI-SAI-KRISHNA]

right, reworded: "The pool never freed a thread to accept the operation."

[MartijnVisser]

@SEPURI-SAI-KRISHNA Can you also open backport PRs to the release-2.3, release-2.2 and release-1.20 branches?

[SEPURI-SAI-KRISHNA]

Thanks for the review and merge. Opening the three backports.

[SEPURI-SAI-KRISHNA]

Backports opened: release-2.3 #29205, release-2.2 #29206, release-1.20 #29207.