Fix race condition in FilteredItemsSelectionDialog initial selection#3547
Draft
vogella wants to merge 1 commit intoeclipse-platform:masterfrom
Draft
Fix race condition in FilteredItemsSelectionDialog initial selection#3547vogella wants to merge 1 commit intoeclipse-platform:masterfrom
vogella wants to merge 1 commit intoeclipse-platform:masterfrom
Conversation
Contributor
Test Results 3 018 files ±0 3 018 suites ±0 2h 24m 44s ⏱️ +29s For more details on these failures, see this check. Results for commit ef70385. ± Comparison against base commit 799f52a. ♻️ This comment has been updated with latest results. |
33748d2 to
20be442
Compare
The flaky ResourceInitialSelectionTest failures were caused by a race condition in FilteredItemsSelectionDialog.refresh() where setSelection() was called immediately after tableViewer.refresh(), before the table had fully updated its items. Root cause: - FilteredItemsSelectionDialog.refresh() calls tableViewer.refresh() (line 874) - This triggers async table updates, especially for virtual tables - setSelection() was called immediately after (line 883), assuming refresh was complete - On slow systems, the selection would be applied to an incomplete table and silently fail, resulting in empty selection: expected:<[...foo.txt]> but was:<[]> The issue manifested as flaky test failures: - testMultiSelectionAndSomeInitialNonExistingSelectionWithInitialPattern - testSingleSelectionAndOneInitialSelectionWithInitialPattern - testMultiSelectionAndTwoInitialSelectionsWithInitialPattern These tests would intermittently fail with "Two files should be selected by default" or "One file should be selected by default" assertions. Solution: Wrapped both selection application paths in Display.asyncExec() to defer selection until after the table refresh completes: 1. For preserving previous selection: - Changed from: tableViewer.setSelection(new StructuredSelection(...)) - Changed to: Display.asyncExec(() -> tableViewer.setSelection(...)) 2. For default first item selection: - Changed from: table.setSelection(0) - Changed to: Display.asyncExec(() -> table.setSelection(0)) Both paths now include disposal checks to prevent errors if the dialog is closed before the async execution runs. The test's existing waitForDialogRefresh() method processes these async events through its processUIEvents() calls, ensuring selections are applied before assertions run. Updated the comment to reflect the asyncExec fix. Verified with multiple consecutive test runs - all 13 tests pass consistently. Fixes: eclipse-platform#294 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <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
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.
The flaky ResourceInitialSelectionTest failures were caused by a race condition in FilteredItemsSelectionDialog.refresh() where setSelection() was called immediately after tableViewer.refresh(), before the table had fully updated its items.
Root cause:
and silently fail, resulting in empty selection: expected:<[...foo.txt]>
but was:<[]>
The issue manifested as flaky test failures:
These tests would intermittently fail with "Two files should be selected by default" or "One file should be selected by default" assertions.
Solution:
Wrapped both selection application paths in Display.asyncExec() to defer selection until after the table refresh completes:
For preserving previous selection:
For default first item selection:
Both paths now include disposal checks to prevent errors if the dialog is closed before the async execution runs.
The test's existing waitForDialogRefresh() method processes these async events through its processUIEvents() calls, ensuring selections are applied before assertions run. Updated the comment to reflect the asyncExec fix.
Verified with multiple consecutive test runs - all 13 tests pass consistently.
Fixes: #294
🤖 Generated with Claude Code