Attempt to fix flak WP table spec

[klaustopher]

Fix flaky work package table widget spec on my page

Problem

work_package_table_spec.rb:79 was intermittently failing after a page reload with:

expected not to find visible css ".subject" with text "WorkPackage No. 24", found 3 matches

The table rendered in its default (unfiltered, all-columns) state instead of the saved filter + column configuration.

Root cause

WidgetWpTableComponent auto-saves the query via an RxJS subscription on querySpace.query.values$() with a skip(2) guard. When the column configuration modal is closed (Apply clicked), the save is triggered through a reactive chain:

column state update → query space emits → ensureFormAndSaveQuery() → HTTP PATCH

This chain involves enough async hops that wait_for_network_idle called immediately after the click could fire during a brief window before the PATCH request was initiated — the network was already idle at that point, so Ferrum returned prematurely and the browser navigated away before the save completed.

On reload the server returned the original, unsaved query, causing both the filter and column changes to appear missing.

Fix

Two ordering changes to the spec:

Before the reload — move wait_for_network_idle to after the DOM assertions that confirm the column removal. have_no_css(".subject", ...) forces Capybara to retry until Angular has updated the DOM, which guarantees the RxJS chain has fired and the PATCH is in-flight. Only then does wait_for_network_idle confirm the request completed.

After the reload — move the widget title assertion (have_field("editable-toolbar-title", with: "My WP Filter", wait: 10)) to before the negative assertions. The title comes from the grid API; waiting for it to appear confirms the widget is initialized from persisted state. A second wait_for_network_idle then catches the subsequent query and results fetches before any negative assertions run.

[HDinger]

👏