Queue cache reads and mutations lack operation and credential ownership

[Chris0Jeky]

Summary

frontend/taskdeck-web/src/store/queueStore.ts exposes one request-list cache, one stats cache, one shared loading Boolean, and one shared error. Every read and mutation currently commits success, failure, toast, loading, and finally state unconditionally.

This is a source-traced finding on main 307c3b8b50bec1cb0bfaea3e570a942bcb1d4451. AutomationQueueView loads requests and stats together, starts replacement request reads when the status tab changes, and refreshes both surfaces after processing. These overlaps are reachable through ordinary operator use.

Confirmed ownership gaps

1. Cross-query request overwrite: an older fetchUserRequests() or status-filter read can replace the result of a newer request-list query.
2. Read-after-write rollback: a request read begun before successful submit or cancel can later erase the submitted item or reinsert the cancelled item.
3. Stale stats: a stats read begun before submit, cancel, or process-next can commit counts that predate the confirmed mutation.
4. Shared-loading race: completion of requests, stats, or a mutation clears loading even while another operation still owns visible work.
5. Shared-error race: an obsolete failure can overwrite a newer success, while an unrelated operation can erase the only current failure receipt.
6. Credential replacement: logout/login, same-user token rotation, or demo-session replacement does not clear the queue cache or invalidate in-flight reads/mutations. Late old-session work can repopulate state or emit toasts into the replacement session.

The original transport promise should still settle to its caller. This concerns truthful client state and does not claim request cancellation or a server authorization bypass.

Expected parent contract

• One latest-read owner for the shared request-list surface, regardless of user/status query kind.
• One independent latest-read owner for stats.
• Successful submit/cancel/process-next invalidates older request and stats snapshots that may predate the write.
• All operations own loading through operation tokens; one settlement cannot clear another active operation.
• The shared error receipt is owned by the operation that produced it, so stale/unrelated work cannot erase or replace it accidentally.
• Identity, token, authentication, or demo-session replacement synchronously clears queue state and advances a credential epoch before old settlements can commit.
• Stale successes/failures still resolve or reject to their original callers but cannot patch state, emit toasts, or clear replacement-session loading/error.
• Requests and stats remain independently concurrent. Existing demo behavior, endpoints, DTOs, view workflow, and public store API remain unchanged.

Acceptance

• Real Pinia/Vitest deferred regressions for reverse-settling user/status reads.
• Read-before-submit and read-before-cancel cannot undo confirmed local writes.
• Stats begun before a successful mutation cannot install a pre-mutation snapshot.
• Independent requests/stats concurrency remains available and loading remains true until the final active operation settles.
• Stale failure after newer success rejects its caller without changing current cache/error/toasts.
• $reset() and same-user token rotation clear both caches synchronously and suppress late read and mutation UI.
• Existing queue store, polling, integration, demo, and Automation Queue view suites remain green.
• Frontend lint, typecheck, production build, full Vitest on Ubuntu and Windows, and complete exact-head hosted CI pass.

Scope boundary

This parent owns cache/read/write/session settlement integrity. Same-request mutation serialization or cross-device revision control should be tracked separately if source/runtime evidence establishes it; do not widen this slice into backend queue semantics.

Audit provenance

Found while continuing the 2026-09-21 asynchronous state-ownership pass after integrations, permissions, agents, notifications, Activity history, and metrics. Searches for an open issue naming queueStore.ts found no existing owner.