Rei 097fa6dca7

fix(frontend): fence a confirmed background-task cancellation against stale polls (#7914) ...

A background-task detail or list read issued before the user cancels can
resolve after the mutation's success handler and overwrite the confirmed
"cancelled" snapshot with the pre-cancel "working" one, so the expanded card
shows the task as active again (and polling resumes) until a later response
corrects it.

useCancelBackgroundTask now awaits cancelQueries for the thread's
["background-tasks", threadId] prefix before seeding the confirmed detail and
list entry, so a read that started before the cancel is dropped instead of
landing afterwards. The following list invalidation is unchanged, so a mounted
card still refreshes from the server. This is the same ordering contract as the
memory mutations fixed in #6959.

Regression: frontend/tests/unit/core/background-tasks/hooks.dom.test.tsx uses a
real QueryClient with deferred detail and list reads; it ends on "working"
without the fix and keeps "cancelled" with it.

Co-authored-by: REI-330 <173389910+REI-330@users.noreply.github.com>
Co-authored-by: AochenShen99 <sac1063467113@hotmail.com>

2026-11-06 10:29:57 +08:00

..

api.test.ts

feat(mcp): complete durable task notifications and chat UI (#4833)

2026-08-22 16:53:32 +08:00

hooks.dom.test.tsx

fix(frontend): fence a confirmed background-task cancellation against stale polls (#7914)

2026-11-06 10:29:57 +08:00

types.test.ts

fix: make MCP notification recovery rollback-safe (#5908)

2026-09-27 20:46:56 +08:00