A Flowable job-acquisition race no longer fails whichever test is polling - #7682
Merged
delchev merged 2 commits intoOct 5, 2026
Conversation
…ling Awaitility catches uncaught exceptions from every thread while an `await()` is running and rethrows them on the test thread, and the framework polls through `await()` almost everywhere. So a Flowable async-executor thread that could not lock a timer job failed `IntentEmissionCoverageIT` on a PR that had touched nothing but generated markup. The stack carried no test frame at all, and Flowable recovers from the contention on its next acquire cycle. `IntegrationTest` registers one global ignore predicate matching exactly that: a `FlowableOptimisticLockingException` raised from `ExecuteAsyncRunnable`, matched by class name so the test framework keeps no Flowable dependency. Awaitility consults the same predicate for an uncaught exception as for one thrown inside a condition, so the whitelist is the whole change. Everything else still fails the test, from any thread, and so does anything thrown inside an await's own condition. Fixes eclipse-dirigible#7581 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The ANTLR parser sources and the minified Monaco client are build output of the worktree they were committed from, not part of this change. The formatter validation rejects them, and they belong to nobody here. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #7581
Awaitility catches uncaught exceptions from every thread while an
await()is running and rethrows them on the test thread, and the framework polls throughawait()almost everywhere (RestAssuredExecutor,AwaitilityExecutor,IntegrationTestitself). Nothing ever turned that off — there was nodontCatchUncaughtExceptionsanywhere intests/.So a Flowable async-executor thread that could not lock a timer job failed
IntentEmissionCoverageITon a PR that had touched nothing but generated markup. The stack carried no test frame at all, and Flowable recovers from the contention on its next acquire cycle.The second option in the issue, taken as narrowly as it reads.
IntegrationTestregisters one global ignore predicate matching aFlowableOptimisticLockingExceptionraised fromExecuteAsyncRunnable— the one exception type, from the one class that acquires jobs. It is matched by class name, so the test framework keeps no Flowable dependency; that is the only thing it ever needs to know about Flowable.ConditionAwaiter.uncaughtExceptionconsultsConditionSettings.shouldExceptionBeIgnoredbefore storing a throwable, which is the same predicate the condition path uses, so registering it is the whole change —catchUncaughtExceptionsstays on. Everything else still fails the test, from any thread, and so does anything thrown inside an await's own condition.