Fix flaky ensureCleanUpAddonCleansUp by holding CleanupAddon strongly#3896
Merged
vogella merged 1 commit intoApr 17, 2026
Merged
Conversation
Contributor
Contributor
Author
|
@ptziegler looks like we finally nailed it. For tip that you could reproduce the test failure if you run the test 100 times was the golden nugget which helped to solve this. |
The test created the CleanupAddon via ContextInjectionFactory.make(...) without keeping the returned reference. The DI framework only holds injected objects via WeakReference (InjectorImpl.injectedObjects), so GC could collect the addon between event registration and event firing. Once collected, the @UIEventTopic handler observed requestor.isValid() == false and silently unsubscribed without invoking the addon's method. The asyncExec that would have set partStack toBeRendered=false was never queued, leaving the assertion to fail. Storing the addon in the application context keeps a strong reference for the lifetime of the test, matching how addons are referenced in production via the application model. Reproduced locally (Linux, DISPLAY=:1) at ~1.2% failure rate over 500 iterations of the test. With the fix, 500 iterations all pass. CI also ran the test 500 times across all platforms (green) before this commit removed the temporary @RepeatedTest(500) annotation. The same pattern is applied to testBug332463 and CleanupAddonTest, which had the same latent issue. Refs eclipse-platform#3581
vogella
force-pushed
the
fix/cleanup-addon-gc-flake
branch
from
9216956 to
5cd5011
Compare
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
1 participant
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.
Summary
PartRenderingEngineTests.ensureCleanUpAddonCleansUphas been flaking for a long time (#3581). Prior fixes (synchronous cleanup; extraspinEventLoop()between hides) addressed wrong root causes — the synchronous fix had to be reverted because it broke the Welcome screen (#3784), and the event-loop fix did not stop the flake.Root cause
The test creates the addon via
ContextInjectionFactory.make(CleanupAddon.class, appContext)and discards the returned reference. The DI framework holds injected objects only viaWeakReference(seeInjectorImpl.injectedObjects). When GC collects the addon between event registration and event firing, the@UIEventTopicdispatcher (UIEventObjectSupplier.UIEventHandler.handleEvent) observesrequestor.isValid() == falseand silently unsubscribes — the addon method is never invoked, theasyncExecthat would have unrendered the part stack is never queued, and the assertion fails.Reproduced locally on Linux with the test trace clearly showing the
TBR partStackBC -> falseevent missing on every failure.Fix
Store the addon in the application context. The context holds it strongly for the test lifetime; this also matches how addons are referenced in real applications (via the application model). The same pattern is applied to
testBug332463andCleanupAddonTest, which had the same latent issue.CI verification
A previous revision of this PR wrapped the test in
@RepeatedTest(500)to run it 500 times across all CI platforms — all green. Locally (Linux) before the fix: ~1.2% failure rate over 500 iterations; with the fix: 500/500 passed. The@RepeatedTest(500)annotation has now been removed and the test is back to a single@Test, ready for merge.Fixes #3581