Spanner queues need an external-action replay test

Draw the transaction boundary before accepting the architecture

For each proposed queue, name the business transition committed in Spanner and every effect that occurs outside that transaction. Preserve the database and instance, edition, schema and queue definition, task identifier, payload contract, enqueue condition, schedule, lease and acknowledgment behavior, worker identity, retry policy, external destination, downstream idempotency contract, reconciliation owner, retention, and rollback path. A state row and task inserted atomically can close the gap between those two Spanner writes. It cannot atomically include an email provider, payment rail, identity system, SaaS API, human decision, or physical process unless that separate system exposes and honors a suitable contract.

Classify the promised outcome with precise language: transactionally enqueued, available for pull, leased, attempted, accepted by an external endpoint, durably completed, reconciled, or approved by a person. Keep at-least-once delivery, at-most-once acknowledgment, and exactly-once business effect as different claims. Record where the task identifier survives, how long the downstream system remembers it, what response proves acceptance, and which effects cannot be reversed. If a provider or application owner cannot identify that boundary, the design cannot inherit an exactly-once label from the database feature.

Force duplicates, timeouts, and lease races through the full path

Build an acceptance matrix around one representative ordinary task and high-consequence exceptions. Deliver the same task more than once; time out immediately before and after the external action; let a lease expire while a worker is still running; start a second worker; renew a lease; crash before acknowledgment; retry after an ambiguous response; schedule then cancel work; change the payload schema; and make the downstream service unavailable or slow. Preserve task and lease identifiers, transaction and commit evidence, worker and code version, attempt count, downstream idempotency key, request and response metadata without protected payloads, acknowledgment assertion result, external record, reconciliation result, and final human disposition.

A passing test should show that a duplicate reaches the same governed outcome without charging, notifying, granting, deleting, or executing twice; that a stale worker cannot erase another worker's valid lease; and that an ambiguous external result remains unresolved until evidence distinguishes success from failure. Test the exact downstream API and retention window rather than a mock that promises perfect idempotency. Include an endpoint that accepts the action but loses the response, an idempotency key reused with different content, a key that expires before delayed replay, a partial batch, and a manual correction that later collides with automation. Unexplained state or an effect that cannot be reconciled blocks the consequential workflow.

Make reconciliation and stop authority first-class controls

Maintain a reconciliation view that joins committed business state, queue task, lease and attempts, acknowledgment, external-system evidence, compensating action, and accountable decision. Define mutually exclusive states for pending, in progress, externally accepted, confirmed complete, retryable failure, non-retryable failure, ambiguous, canceled, superseded, corrected, and closed. Preserve unavailable evidence as unavailable rather than assuming no effect. Set escalation thresholds by consequence and age, bound automatic retries, and prevent a backlog or poison task from consuming the entire worker fleet. Measures should report both the task denominator and business-effect denominator so a low error rate does not hide a small set of unreconciled high-impact actions.

Name who can pause a queue, one task class, or one external destination; who can approve replay, correction, compensation, customer notice, or permanent closure; and who verifies that the resulting business record is right. High-impact actions affecting money, access, employment, safety, legal rights, or customer commitments should retain the required human judgment and existing specialist process. An agent can draft, classify, or route within an approved boundary, but a queue feature does not grant it broader authority. Maintain an alternate manual or controlled path for cases where the external action is uncertain or the idempotency contract is absent.

Stage general availability as a workload decision

Start with one bounded task class whose external effect is reversible and observable. Pin the Spanner edition, schema, client and worker versions, queue configuration, downstream contract, and test set. Compare the current architecture and queue design using the same workload, Regions, traffic, observation window, failure injections, support model, and cost scope. Measure correct completed effects, duplicates prevented, ambiguous results, reconciliation age, retry and lease behavior, queue delay, worker saturation, database work, downstream demand, operator workload, and total cost. A generally available service status supports procurement and support evaluation; it is not buyer-specific evidence that the workload is safe, faster, cheaper, or resilient.

Require application, data, platform, architecture, service, resilience, identity, security, privacy, records, finance, procurement, accessibility, regulatory, legal, and affected business owners to accept the boundary, evidence, unresolved cases, residual risk, stop rights, and next review date. Reopen the decision after schema, queue, lease, schedule, worker, client, edition, Region, idempotency, external API, retry, reconciliation, retention, or consequence changes. The October 2 announcement is a genuine post-cutoff material development, but the CIO decision remains narrow: whether this declared chain can survive replay and ambiguity without turning provider transaction semantics into an unsupported claim about the final business effect.

Turn this source into a reviewable decision

For AI for CIOs, use this briefing as a dated decision record rather than a substitute for the source. Preserve Google Cloud, Announcing Spanner queues: Transactional messaging for agentic workloads and beyond, the exact URL, the October 3, 2026 review date, the supported facts above, the editorial interpretation, the limitations, and any buyer-specific evidence. Link that record to the decisions most directly affected: Enterprise AI platform architecture; Software delivery and modernization; Operations and incident intelligence; Identity and agent access. State whether the source changes the scope, evidence requirement, control, sequence, or only the language used to describe the decision.

Before action, name the accountable owner, affected population and workflow, exact offering or configuration, source data and rights, human decision point, exception and appeal path, complete cost, expected benefit, failure and stop conditions, retained evidence, and next review date. Keep official facts, provider statements, buyer observations, representative tests, measured outcomes, editorial inferences, and unknowns visibly separate. Reopen the record when the source, offer, model, integration, data, policy, population, responsible person, or measured result changes.

Limitations and unknowns

Google Cloud is the provider and source for the October 2, 2026 announcement and current Spanner queues documentation. The official blog feed establishes a 16:00:00Z publication time after the daily cutoff. The sources support the general-availability statement, atomic state-and-enqueue pattern, at-least-once delivery, at-most-once acknowledgment, task identifier and downstream idempotency pattern, lease and stale-worker behavior, supported editions, and documented limitations. They do not independently establish a buyer's schema, edition, client, worker, task identity, external-system idempotency window, retry safety, acknowledgment behavior, replay result, reconciliation completeness, latency, throughput, cost, security, resilience, compliance, or business outcome. Verify current product documentation and release notes, exact configuration and code, representative duplicate and ambiguity tests, downstream records, reconciliation and incident evidence, and qualified application, data, platform, architecture, operations, resilience, identity, security, privacy, records, accessibility, finance, procurement, regulatory, legal, and business-owner review before consequential production reliance.