From ef63faf33ae4a03d664f2dd188eb8f3be2d1fa3c Mon Sep 17 00:00:00 2001 From: James Pine Date: Thu, 23 Apr 2026 19:41:10 -0700 Subject: [PATCH] fix(captures): refetch readiness immediately after STT/LLM model swap MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit useCaptureSettings updated its own cache optimistically but never invalidated ['capture-readiness'], so for up to 5 s (the poll interval) after switching stt_model or llm_model the checklist kept showing the previous model's ready/missing state. The backend endpoint resolves the model live on each call — it was just the frontend cache that lagged. Invalidate in onSettled only when the patch touched a model field, so unrelated updates (chord keys, toggles) don't pay for a refetch. Co-Authored-By: Claude Opus 4.7 (1M context) --- app/src/lib/hooks/useSettings.ts | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/app/src/lib/hooks/useSettings.ts b/app/src/lib/hooks/useSettings.ts index e6fc49d2..40750be7 100644 --- a/app/src/lib/hooks/useSettings.ts +++ b/app/src/lib/hooks/useSettings.ts @@ -42,8 +42,15 @@ export function useCaptureSettings() { queryClient.setQueryData(CAPTURE_SETTINGS_KEY, ctx.previous); } }, - onSettled: (data) => { + onSettled: (data, _err, patch) => { if (data) queryClient.setQueryData(CAPTURE_SETTINGS_KEY, data); + // /capture/readiness resolves stt_model / llm_model live on each + // call, but its cached response keeps serving the previous + // model's state until the next 5 s poll. Invalidate on model + // swaps so the readiness checklist re-checks immediately. + if (patch.stt_model !== undefined || patch.llm_model !== undefined) { + queryClient.invalidateQueries({ queryKey: ['capture-readiness'] }); + } }, });