fix: refresh the list of view displays before the views themselves

[tkuhn]

The page-level "refresh now" set both refreshes going at once: the resource's structure, and — over the QueryResults on screen — every view query. Both then ran concurrently on the re-rendered page, and since the structure query is often the slower one it landed last. Home page log, click at 20:34:51.749:

20:34:51.801  Refreshing cache for …/get-view-displays
20:34:52.0–52.5  (all 15 view queries refreshed)
20:34:58.243  Updating cached API response …/get-view-displays   ← 7.2 s later

Worse, the views it refreshed were the ones on screen at the moment of the click, i.e. the pre-refresh list. When the refreshed structure landed and RefreshingStructurePanel swapped in the rebuilt ViewList, its views were built straight from the cache and no query refresh was issued for them at all — so a view display that had just been added showed whatever the cache happened to hold.

What this does

The two steps are now sequential: first the list of view displays, then the views that list turns out to contain.

• PageTitleMenu only marks the structure and leaves a view-refresh request standing on the resource, instead of clearing the on-screen views' caches.
• AbstractResourceWithProfile.isViewRefreshDue(waitsForStructure) hands that request to the first view list built once the refreshed structure has landed. The answer is memoised per RequestCycle, so several lists on one page refresh together rather than the first one taking the request away from the others.
• ViewList marks each view's query as outdated just before building it, so the view comes back through RefreshingResultPanel — what is on screen now, plus a spinner — and swaps in the new results once the query has run.
• RefreshingStructurePanel rebuilds its content for a standing request even when the refreshed structure turned out to be the same one; that rebuild is what carries the request to the views.
• forceRefresh now also marks the view-display query itself in ApiCache, the way every other refresh does. Without it, a forced fetch that finds a refresh of the same query already in flight settles for what that one leaves behind — a response fetched before this refresh was asked for.

Views built outside the structure-driven list — the About and Explore tabs build their own — have no refreshed list to wait for and are still marked right away (findParent(ViewList.class) == null). A ?root=-pinned space page fetches its view displays inline, so what it shows is already the refreshed list and it does not wait either.

Trade-off

The views no longer start refreshing immediately: they wait for the structure query. On the home page that is the ~7 s visible above, with the StructureRefreshIndicator spinner running beside the title menu meanwhile. This is deliberate — it is what makes the refreshed list the one whose views get refreshed.

Verification

Full suite green (1192 tests), including three new cases in StructureRefreshTest covering the wait, the explicit-list path and the no-request default.

Driven end-to-end against a local instance. Home page, after the change:

20:34:51.801  Refreshing cache for …/get-view-displays          ← step 1
20:34:58.243  Updating cached API response …/get-view-displays  ← lands
20:34:59.379  Getting view displays …                            ← content rebuilt
20:34:59.58–59.93  (all 15 view queries updated)                 ← step 2

Nothing refreshes between the click and the structure landing. The space page behaves the same; the About tab still refreshes its own nine view queries immediately; pages render clean with no errors.

🤖 Generated with Claude Code