ux(recommendations): Refresh button gives no in-flight feedback or toast confirmation

[cristim]

Symptom

The Refresh button on the Recommendations page (recommendations-freshness-refresh-btn, rendered by frontend/src/freshness.ts:renderFreshness) gave no transient feedback while the underlying POST /api/recommendations/refresh call was in flight: the label stayed Refresh, the button only flipped to disabled (no visible state change), and there was no toast on start or completion. On a slow refresh the user couldn't tell whether the click had registered, was running, or had finished.

Expected behaviour

• Click → button label flips to Refreshing... and becomes disabled.
• Sticky info toast Refreshing recommendations… appears for the duration of the call.
• On success: info toast is dismissed, a 5 s success toast Recommendations refreshed shows, the freshness pill re-renders with the new timestamp, and the button restores itself.
• On failure: info toast is dismissed, an error toast Refresh failed: <message> shows, and the button restores its original label + enabled state. Non-Error throws (null / undefined) must not crash the error handler itself.

Why it matters

A refresh round-trip can take several seconds on accounts with many regions. Without affordances the user is liable to click again, or assume the action did nothing.

Severity

LOW — UX polish only; the underlying refresh always worked.

Resolution

Tracked by PR #52.

[cristim]

Resolved by PR #52 (feat/refresh-button-toast-feedback)

Verified end-to-end against the production bundle (frontend/dist/js/app.1fe42ed8.js, built by the pre-commit hook on commit eb342cf1c) in Chrome with a tiny mock-API server holding the refresh promise open for 1.5 s so the in-flight state is observable.

Phase	Button text	btn.disabled	Toast	Freshness pill
Immediate (post-click)	Refreshing...	true	Refreshing recommendations… (info, sticky)	3h ago
Mid-flight (~600 ms in)	Refreshing...	true	Refreshing recommendations…	3h ago
Post-completion (~2.8 s)	Refresh	false	Recommendations refreshed (success)	Just now

Coderabbit nitpick fix (btn.disabled = true/false instead of setAttribute('disabled', 'true')) confirmed in the shipped bundle: buttonAttrDisabled === "" while in flight (boolean-attribute fingerprint), null after.

Jest coverage: 17/17 in frontend/src/__tests__/freshness.test.ts, including two new cases covering the in-flight rename + success-toast path and the error-path rollback + error-toast path. Typecheck clean.

[cristim]

Resolved by #52 (merged at 2026-04-24T21:52:44Z, merge commit db429fe). Verified end-to-end — see prior comment for the snapshot table.