CANCELLED
GCP CANCELLED means the operation was canceled, typically by caller context cancellation or connection/session teardown.
Last reviewed: February 28, 2026|Source-backed guidance under our editorial policy
Start Here
Use the closest compare guide, playbook, or adjacent error page to narrow the decision faster before you start changing production systems.
This page is part of the Error Reference library. Learn more about the project or report a correction.
What Does Cancelled Mean?
Work ended before completion due to cancellation propagation, so callers must identify the cancel source before deciding whether to retry.
Common Causes
- -Client-side cancellation token or context was triggered.
- -Request was canceled during shutdown or deployment drain.
- -Upstream caller timed out and canceled downstream in-flight work.
- -Connection interruption terminated the RPC before completion.
How to Fix Cancelled
- 1Trace cancellation origin across service hops using correlation IDs.
- 2Separate graceful shutdown windows from active long-running requests.
- 3Tune client timeout and cancellation policy for real latency profiles.
- 4Use idempotent retry logic only when cancellation did not commit side effects.
Step-by-Step Diagnosis for Cancelled
- 1Trace cancellation propagation from caller to callee using correlation IDs and context deadlines.
- 2Identify whether cancellation came from user action, timeout, deploy drain, or transport closure.
- 3Determine if the canceled operation could have committed side effects before cancellation surfaced.
- 4Retry only with idempotency/reconciliation safeguards after cancellation source is addressed.
Cancellation Provenance Mapping
- -Inspect caller context and timeout hierarchy (example: upstream gateway cancels downstream RPC when its shorter deadline expires).
- -Review shutdown hooks and drain behavior (example: rolling deploy terminates in-flight requests before graceful window completes).
Post-Cancel Consistency and Retry Safety
- -Treat canceled mutations as potentially partially applied (example: client sees CANCELLED but backend commit completed moments earlier).
- -Use idempotency tokens and reconciliation reads before replaying canceled write requests.
Seen in Production
Gateway timeout cancels downstream RPCs before backend responds
Frequency: common
Example: Client sees CANCELLED while backend logs show request execution nearing completion.
Fix: Align gateway timeout with backend processing budget and propagate realistic deadlines.
Rolling restart interrupts in-flight mutation requests
Frequency: rare
Example: Worker shutdown sends cancellation signal and leaves uncertain write outcome.
Fix: Add graceful drain plus idempotent replay reconciliation before restart completion.
Debugging Tools
- -Distributed tracing with context deadline propagation
- -Structured cancellation-cause logs
- -Graceful shutdown and drain telemetry
- -Idempotency and reconciliation audit checks
How to Verify the Fix
- -Replay affected flows and confirm cancellation rate returns to expected baseline levels.
- -Validate graceful shutdown sequences no longer cut off in-flight critical requests.
- -Confirm retries after cancellation do not create duplicate or inconsistent side effects.
How to Prevent Recurrence
- -Align deadline and cancellation policies across all service hops.
- -Implement coordinated graceful shutdown with enough drain time for long-running calls.
- -Instrument cancellation source tags in logs and metrics for rapid root-cause isolation.
Pro Tip
- -include a cancellation-cause field in structured logs at every boundary to reconstruct propagation chains quickly during incidents.
Official References
Provider Context
This guidance is specific to GCP services. Always validate implementation details against official provider documentation before deploying to production.