[woodsonl]

Summary

The Compression Hub at the top of /dashboard/context/combos (CompressionHub.tsx) has two controls that save to PUT /api/settings/compression: the active-profile select (activeComboId) and the Context Editing toggle (contextEditing). Both stay enabled while a save is in flight, so saves overlap. saveSettings reverted a failed save to the settings value captured when that save started (useCallback deps [settings, t]), which goes wrong once another save starts in between:

• Change the profile, then flip the toggle before the profile PUT answers. If the profile save fails, the screen goes back to the snapshot from before the profile change and loses the toggle, even though the server stored it.
• If the profile save fails and then the toggle save fails, the toggle's rollback restores its own snapshot, which already held the rejected profile, so the select shows a profile the server never stored.

The Fix

• Saves go out one at a time through one promise chain that every mounted Hub shares. The Hub keeps the last saved settings and shows them merged with its saves still queued. A failed save drops out of the queue, so only its own fields roll back and a newer save keeps its value.
• A Hub waits for the saves already queued before it loads. If you leave the page while a save is pending and come back, the new Hub shows what the server stored, and its own saves land after the older ones. A Hub that unmounts during that wait sends no requests once the wait ends.
• A queued save whose keys a later queued save all carries is skipped, because the later PUT replaces those keys anyway. Three quick profile changes while the first PUT is pending send two PUTs.
• Each PUT carries AbortSignal.timeout(15_000). A PUT with no answer by then counts as failed, so one stalled request cannot hold the queue.
• A failed save's error clears when a later save stores every field it had failed, or at the next edit. A save of another field can no longer leave the banner up forever, and the next edit still dismisses it.
• While a save is queued or in flight, the page asks before unloading (beforeunload), so leaving cannot silently drop a save the queue was still holding.
• Each PUT still carries only the changed field (fix(api): api/settings/compression save failed #6039).
• CompressionSettingsTab has used a per-tab version of this queue since fix(compression): settings tab saves only the fields that changed #14723. The Hub's queue is shared across mounts, because a per-Hub queue let a save from a newly mounted Hub land before an older queued one. The ordering holds within one browser tab; another tab keeps its own queue.

Validation

Check	Result
Overlap tests on the base code (the first commit adds only the tests)	4 of the 5 new cases fail: the toggle shows off after a failed profile save the toggle outlived, the select shows c1 after both saves fail, three PUTs go out where two should, and the toggle PUT goes out while the profile PUT is stalled. The fifth case (a later save fails, the earlier one is kept) passes before and after.
Remount tests on the per-Hub queue (the third commit adds only the tests)	both fail: the new Hub shows stale values, and it lets its own save go out before the old Hub's queued save
Second-round tests on the queue as first shipped (the eighth commit adds only the tests)	3 of the 4 new cases fail: the banner stays up after a later save stores the failed field, no unload prompt while a save is pending, and an unmounted Hub still sends its settings GET after the queue drains. The fourth (the banner clears at the next edit) pins existing behavior and passes before and after.
The four Hub test files at the head	22/22 pass
All compression and Hub UI test files at the head	26 files, 102/102 pass
Adversarial probes (orderings, mounts, queue mechanics, error display, timeout, two Hubs)	5 scenarios, all pass
StrictMode probe (one PUT per change, per-field rollback, GET-500 fallback)	3/3 pass
Codex review of the diff	2 findings reproduced and probed: both are pre-existing limits the base produces identically (cross-tab staleness across two browser tabs; two Hub copies in one module cannot coexist in the product). Details in Reviewer Notes.
Independent red-team and adversarial code passes on the head	both SHIP: no blocker; every constructed failing sequence resolves correctly
Server render and live routes (dev server, scratch data dir)	Hub HTML renders server-side; login, settings GET, combos GET all 200
Dashboard typecheck gate, ESLint and Prettier on the changed files, i18n guard, pre-commit gates	pass
Interactive browser pass with forced PUT failures	not completed: the automation webview cannot finish rendering any dashboard route under the Next dev server (pages without this change hang the same way). The server render check above and the jsdom DOM probes cover what the browser pass would have exercised.

These .tsx tests run under vitest.config.ts (npm run test:vitest:ui). CI runs that suite in ci.yml, which triggers for pull requests into main, so the runs above are local; the suite next runs in CI on the release pull request.

Tests Added Or Updated

tests/unit/ui/compressionHub-active-selector.test.tsx gains a fake route that stores what each successful PUT carries, can hold each PUT, and fails the PUTs that carry chosen keys, so a test decides the order in which saves answer and checks the stored settings:

1. A failed profile save rolls back only the profile and keeps the toggle save the server stored; the error stays visible after the toggle save succeeds.
2. A failed toggle save after a failed profile save leaves both controls at their saved values.
3. A failed toggle save after a successful profile save keeps the profile.
4. Three quick profile changes while the first PUT is held send two PUTs, and the select ends on the last choice.
5. A Hub mounted while another Hub still has saves queued shows what the server stored.
6. A Hub mounted while saves are queued stays in its loading state until they land, so its own save lands last.
7. A PUT that never answers fails when its 15-second timeout fires, and the toggle save queued behind it then goes out.
8. The error clears when the user makes the next edit.
9. The error clears once a later queued save stores the field that failed.
10. The page asks before unloading while a save is queued or in flight, and stops asking once the queue drains.
11. A Hub unmounted while its load waits on the queue sends no settings GET after the wait ends.

The harness gains a second named combo for case 4.

Reviewer Notes

• A PUT that the server stores after the 15-second timeout still counts as failed and rolls back on screen; the screen and the server can then disagree until the next save or remount re-syncs. This is the price of treating a timeout as a failure (the route does not observe the client's abort signal); a fresh Hub always shows the stored value.
• After a failed save, the banner is driven by the set of fields whose latest save failed: it clears when later saves store all of them, or at the next edit. A next edit also clears failures of other fields that are still unstored; the rolled-back values stay on screen either way. This matches fix(compression): settings tab saves only the fields that changed #14723.
• A Hub that mounts while a PUT is stalled stays in its loading state until that PUT answers or times out.
• The select and the toggle stay enabled; a queued change shows on screen at once.
• The shared queue orders saves within one browser tab. Two tabs can still overwrite each other on the server, as before this change; each tab shows its own last-saved copy until a remount.
• The queue's promise chain has no catch of its own. Nothing in the task body can throw today (the fetch, its timeout, and network errors are all caught), but a future edit that throws there would stall every later save in the tab and hang future Hubs on their loading state. Hardening the tail is a sensible fast follow.
• AbortSignal.timeout is treated as available, matching the ten existing client/server usages in the repo; on a browser without it every save would report failure.

⚠️ base-red inherited: #15306