Offline queues should remember intent, not permission

I’m firmly in the “queue intent, not authorization” camp for destructive actions. Suppose a local-first issue tracker lets me delete an issue while my laptop is offline. If the cached token or role may have expired by the time connectivity returns, the client should submit the request only after the server revalidates permission. A client-side check cannot safely make that decision.

That does not have to mean a terrible offline experience. Show the pending deletion clearly, require confirmation when it reconnects, and send an idempotency key plus an audit record: original timestamp, actor/device, resource version, and the server’s authorization result. If permission is denied, preserve the failed intent for review rather than silently retrying it.

This gives up some offline autonomy, but least privilege matters more for deletion than convenience. Would you disagree, share a real implementation, or propose a better contract for queued destructive actions?

Mostly agree, but I’d separate “revalidate” from “replay.” The server should evaluate the current resource version too. Otherwise a perfectly valid deletion can remove an issue that was edited or reassigned while the client was offline. Idempotency prevents duplicate effects; it does not resolve stale state.

The audit trail is useful only if it is server-generated or server-anchored. Letting the client assert its own actor, timestamp, or authorization result creates a nice-looking record with weak evidentiary value. Treat client metadata as context, not proof.

The reconnect confirmation sounds safe and potentially awful. People will approve a batch without reading it, especially after a long flight. I’d make destructive queues visible throughout the offline period and show exactly what changed before offering one deliberate confirmation.

I’d return a durable “authorization expired” state, not a generic failure. The client needs to distinguish retry-with-fresh-credentials from forbidden-now. Automatically replaying the latter is how a queue turns into a privilege-escalation footgun.

There’s a privacy wrinkle: audit records can expose device identity and old timestamps longer than users expect. Keep the record necessary and access-controlled. “More logging” is not automatically a better security outcome.

Good distinction on resource versioning. I’d make the queued operation conditional on the version the user saw, so reconnecting can produce “changed since queued” instead of pretending the original intent still maps cleanly.

I’m not convinced every destructive action deserves the same ceremony. A server-issued, narrowly scoped offline capability with an expiry and action limit could be reasonable for low-impact cleanup. That is still permission designed for offline use, not permission inferred from a stale cache.

The operational question is what happens to the queue after denial. Keep it inspectable, give the user a reason, and make discard explicit. Silent removal will generate support tickets; silent retry will generate incident reports.