The incident report that omitted a paused queue
A museum operates queues for membership renewals, ticket confirmations, and collection intake. A technician checks the first page returned by the Cloud Tasks queues list API and declares that no paused queues remain. A second queue, excluded from that page or located in another region, never appears in the report. That is a reporting failure, not a task-processing failure. The `projects.locations.queues.list` API is a read operation that returns queues from a specified location, along with a continuation token when additional pages exist. Its response cannot stand in for an organization-wide inventory unless the caller has included every relevant location and iterated through every page.
Scope the audit to projects and locations
The REST method uses a parent such as `projects/PROJECT_ID/locations/LOCATION_ID`. That parent is part of the query contract, not an optional label. Create an approved list of projects and locations used by the notification system and identify which team owns each queue. A location inventory can be built separately, but its result also needs review; do not assume every region is in scope or that listing one location covers the others. Capture the environment and timestamp with each page. A queue absent from one location may exist in another, and permissions can also affect what the current operator is able to see.
Apply filters without turning them into blind spots
Cloud Tasks supports a `filter` parameter on queue listing, including conditions such as `state: PAUSED`. Filters are useful for a targeted review, but filtered inventory should not be confused with all queues. For a comprehensive operations report, first define whether the report covers every queue or only a selected state. Use the same filter string for all pages in one traversal; the API documentation says changing the filter while iterating is an error. Save the filter in the report header. A queue can change state while a scan is underway, so treat the output as a snapshot attempt, not an immutable transaction.
Understand pageSize and nextPageToken
The method accepts `pageSize` and returns `nextPageToken` when there are additional results. The documented maximum requested page size is 9,800, but the server may return fewer entries than requested even if more exist. The number of returned queues is therefore not a completion signal. Continue while the response contains `nextPageToken`, and stop only when the token is empty. Send that token back as `pageToken` with the same parent and filter. Tokens have a limited validity period, documented as two hours. An old bookmark is not a durable way to resume a long-running audit days later.
Build an append-only audit ledger
For each returned queue, record its resource name, location, state, scan time, and the page on which it was observed. Avoid copying unrelated sensitive configuration values into a public spreadsheet. De-duplicate by resource name in a working ledger, but retain enough scan metadata to explain whether a record was seen twice during an active change window. If a page fails, restart the affected traversal using a fresh token chain instead of marking unseen queues as healthy. Keep the inventory report separate from actions such as purge, pause, or resume; a read-only audit should not mutate queue state.
Distinguish a paused queue from a stopped workflow
A queue state is useful operational data, but it does not prove every individual delivery succeeded or failed. An application might produce messages through another project or service, and tasks already dispatched may require their own history review. A paused queue should trigger an ownership question: was the pause authorized for maintenance, a policy hold, or an emergency? Do not resume it simply because the inventory caught it. Record the related incident ticket and consult the people responsible for visitor communications before modifying anything. That separation protects users from accidental replays of stale notifications.
Account for concurrent changes and partial scans
Cloud environments change while an inventory runs. Another operator might create a queue or change its state between pages. A location may return an authorization error even though other regions succeed. Label those cases as partial coverage instead of silently presenting the report as complete. Preserve error codes, the affected location, and the exact scan window. For critical decisions, perform a second read after maintenance activity settles and compare the queue names and states. A difference between reads is evidence to investigate, not permission to delete or recreate a queue.
Publish a safe report for operational review
A good paused-queue report has a defined scope, a record count, a list of inaccessible locations, and a clearly labeled final-page status. It should show who reviewed the inventory and which action tickets remain open. The reporting system should not expose task payloads, visitor emails, authentication headers, or unrelated application data. Where a queue is missing from the approved inventory, the next step is to verify resource ownership and IAM, not to create another queue with the same name. The list endpoint provides discovery, not a complete delivery audit or a data-retention compliance verdict.
Test pagination before relying on automation
Build a test project with several harmless queues and use a deliberately small `pageSize` so the script is forced to follow multiple tokens. Check an empty region, a filtered scan, a state change during traversal, and an IAM denial. Verify that the export includes the same filter on every request and never declares success after a short page that still has `nextPageToken`. Then run the reader with the least privilege required for queue listing. Schedule periodic inventory comparisons, with an explicit manual review path for inconsistencies; do not automatically resume or purge queues based on a newly generated list.
How We Research
This article is based on the official Cloud Tasks queues.list REST method, the Queue resource reference, and the locations.list API. We checked the documented parent path, filters, page-size caveats, IAM requirement, and continuation-token behavior. The museum operations example and illustrations are hypothetical. We did not enumerate any live queues or assert that a listing provides a perfectly consistent snapshot during concurrent changes.
Frequently Asked Questions
No. Follow nextPageToken until it is empty; the API can return short pages before completion.
No. The documented listing contract requires the same filter through the token traversal.
No. Each request has a specific projects/locations parent. Audit each approved location.
No. Queue state alone does not determine task history or downstream delivery outcomes.
It should not. Keep the read-only inventory separate from authorized state-changing operations.