Fix flaky team planner and calendar sort specs#24000
Merged
Merged
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
This PR stabilizes the flaky Selenium feature spec around sorting in the Team Planner overview by making the page-object assertion resilient to full-page reloads triggered by sort header clicks.
Changes:
- Reworks
Pages::TeamPlanner#expect_views_listed_in_orderto use retrying Capybara matchers instead of a one-shot DOM snapshot. - Adds inline documentation explaining why sorting causes asynchronous row replacement and why retrying matchers are required.
a42da97 to
5f07a25
Compare
The shared `expect_views_listed_in_order` helpers snapshotted the table rows with a non-retrying `eq`. The sortable column headers navigate via a full browser visit (their links carry `target: "_top"`, so Turbo Drive does not intercept), replacing the table asynchronously. When the assertion ran before the post-sort document settled it read the previous order, failing intermittently in CI while passing locally. Replaces the snapshot with retrying Capybara matchers that re-query the scoped table body until the expected order appears, and mirrors the fix in the identical calendar helper to keep the two copies consistent. Co-authored-by: myabc <755+myabc@users.noreply.github.com>
5f07a25 to
da73e12
Compare
team_planner_overview_spec sorting example
|
Warning This pull request does not link an OpenProject work package. Please add a link to the work package in the description, or reference it in the |
team_planner_overview_spec sorting example
HDinger
approved these changes
Jul 1, 2026
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Ticket
n/a
What are you trying to accomplish?
Stabilizes the flaky CI failure in
team_planner_overview_spec.rb[1:4:4:1]("allows sorting by all columns"), and applies the same fix to the identical (and equally racy) helper in the calendar module.What approach did you choose and why?
The sortable column headers navigate via a full browser visit, not a Turbo Stream:
sort_header_tag→sort_link→link_to_content_updaterenders the link withtarget: "_top", and Turbo Drive does not intercept links carrying atarget. So clicking a header triggers a full page reload that replaces the table asynchronously.Pages::TeamPlanner#expect_views_listed_in_ordersnapshotted the rows once (all("tr td.name").map(&:text)) and compared them with a non-retryingeq. When the assertion ran before the post-sort document settled, it read the previous order and failed. Locally the lighter page settles before the snapshot, hiding the race; CI's compiled frontend and parallel load expose it.The fix replaces the snapshot with retrying Capybara matchers that re-query the scoped table body until the expected order appears, so the assertion tolerates the reload instead of racing it.
exact_text:preserves the exact-match semantics of the originaleq. The change is scoped to the two spec page objects; no production code changes.Merge checklist