Apply runner filters to requests/iterations as well as tests [INS-3348] - #10353
Draft
godfrzero wants to merge 3 commits into
Draft
Apply runner filters to requests/iterations as well as tests [INS-3348]#10353godfrzero wants to merge 3 commits into
godfrzero wants to merge 3 commits into
Conversation
✅ Circular References ReportGenerated at: 2026-08-07T22:16:05.755Z Summary
Click to view all circular references in PR (9)Click to view all circular references in base branch (9)Analysis✅ No Change: This PR does not introduce or remove any circular references. This report was generated automatically by comparing against the |
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.
Using the Passed/Failed/Skipped filters in the collection runner results currently only filter through tests, leaving requests/iterations in place even if there are no matching children.
This can lead to a degraded experience in scenarios where there may be a large number of requests/tests/iterations with very few failures/successes. Engaging a filter in such a case will still lead to a significant amount of screen real estate being dedicated to "empty" requests/iterations, thereby still necessitating that the user manually scroll to find the test that's failing/passing/skipped. This PR updates the filter logic to:
Since it's now possible for the entire pane to be empty if nothing matches a filter, this PR also adds a very basic empty state:
Changes were tested manually by running collections of various sizes for 1-10 iterations, and automated tests have also been added to verifythe internal business logic. Tests to actually run through the GUI have not been added since they've proven to be a source of flakiness, and the business logic-only tests should be good enough IMO.