Check the queue without consuming a message
Use the installed SQS origin endpoint, signing Region, and existing IAM workload profile with the actual queue URL. Set these placeholders from the application configuration;SQS_ENDPOINT_URL is distinct from the report service’s T9_ENDPOINT_URL.
409 ExplainedNotPerformed preview is not a queue-attribute result or evidence that the queue is missing. Some attributes are approximate, delayed, unavailable, or declared rather than live on particular mappings. Do not infer that a message is absent from one count. Compare the returned queue ARN, account, Region, queue type, and installed target profile before investigating delivery. A ReceiveMessage call is different: it can claim messages and start their visibility timeout, even if the consumer later crashes.
Request live counts separately when the selected backend has an authoritative source. Pure Pub/Sub has no SQS count authority in this design; AMQP alone does not provide Service Bus backlog counts. Unavailable requested attributes must produce an explicit unsupported result, rather than an empty success or zero. Declared settings are not live observations. On PostgreSQL, visible, in-flight and initially delayed categories come from one message-state snapshot, but can change immediately afterward. Count scans consume pool/I/O capacity even when one field is requested. Neither zero depth nor an empty receive proves application completion: purge, expiry and dead-letter transfer can remove backlog.
Read the batch response as well as its HTTP status.
SendMessageBatch and DeleteMessageBatch can return per-entry failures after a successful HTTP response. Preserve each entry ID and error code. A service error remains the SDK’s native SQS result; an explanation report records adapter decisions separately. Network or SigV4 failures may leave no report receipt.
For Pub/Sub, the receipt is a native acknowledgement ID for one delivery on the selected subscription. Delete and visibility changes use that subscription and ID, not a lookup of the original stream. Closing the stream alone proves neither invalidity nor continued effectiveness. Restart interrupts local buffering; graceful retirement can release still-buffered work, but already handed-off deliveries are outside that drain. The mapping provides no qualified SQS-style durable-receipt guarantee across restart. Check deadline and redelivery history: a post-deadline ACK can return success while the message is later delivered again. Use the current delivery’s receipt and independent business-state evidence rather than diagnosing every old-handle result as restart invalidation.
Worked case: a job reappears after a slow worker
A worker receivesinvoice-1001, starts a six-minute database task, and sees the same job again. First inspect the queue’s VisibilityTimeout and the receive attempt’s timestamp. If visibility was 120 seconds, a second receive after that interval is expected when the first worker has not deleted or extended the claim. Compare both receipt handles; delete or change visibility using the current handle, following that backend’s rules. A Service Bus mapping caps requested visibility at five minutes and its broker-lock handles do not survive an adapter restart. PostgreSQL mappings store durable handles, but a stale claim still fails. Confirm the selected profile before changing the timeout.
FIFO uses MessageGroupId and explicit or configured content-based deduplication: an unsettled head blocks later group work, and repeated dedup IDs can suppress sends. Direct PostgreSQL allows one in-flight message per group, so measure receive-to-settlement time rather than assuming a ten-message same-group pipeline. Native Service Bus has bounded receiver slots, different duplicate-send responses and no durable ReceiveRequestAttemptId replay. Transactional Cosmos and the Firestore/Spanner or SQL-assisted ordered-batch designs have their own conservative batch/attempt restrictions. Confirm the FIFO mapping before interpreting a blocked group or replay result.
Queue Storage requires a separate check before visibility extensions: its native update rotates the pop receipt, while SQS returns no new handle. A qualified retained alias mapping must preserve the original handle over the supported replica/restart scope. The native design does not specify that authority; without qualification the supported contract requires refusal before effects. Do not treat initial-token portability as proof that post-update operations work on arbitrary replicas.
Do not send the job again to diagnose it. Check the application’s durable job ID and downstream completion first. If the send response was lost, reconcile message and business state before deciding whether a new send is safe. AWS visibility guidance explains why an unacknowledged message can become visible again.
Use a report for a specific request
For a non-executing request check, confirm installed capture support for that operation, then add a signed version-1x-t9-explain control with mode Explain before signing. A completed preview returns 409 ExplainedNotPerformed with a receipt; unsupported capture can return a refusal. ExecuteAndExplain and x-t9-explain: true execute the SQS operation; a preview of ReceiveMessage must not be treated as a claim. Do not use an executing control to replay an uncertain send or delete.
Save the native status, SQS error code, request ID, x-t9-explain-id, and receipt expiry. Read the existing report with T9CloudAdapter.GetExplanation on the install’s published t9 endpoint, SigV4 service t9, published signing Region, and the same report owner’s IAM credentials and session token. The signed SDK flow can read an existing report without rerunning the queue operation. A receipt does not prove that asynchronous target work finished; inspect report lifecycle and follow asynchronous explanations where applicable.
PostgreSQL-backed queues may eventually include full PostgreSQL plan evidence for qualified operations. Availability depends on the installed version and backend. Plans can expose physical relation names and predicates, are owner-only, and describe a separate committed-state estimate. They do not prove a message was delivered, deleted, or dead-lettered. Use the queue attributes, exact message identity, native result, and downstream state for those conclusions.
Worked comparison: send one job through different backends
Suppose the application sendsinvoice-1001 once and receives a successful SendMessage response. Keep the native message ID and any report receipt. Classic can map to a PostgreSQL insert, native Service Bus send or Pub/Sub publish. SQL-assisted FIFO adds its own durable acceptance and transport steps. The Classic and FIFO profiles describe those different mechanisms; installed runtime and capture support must be checked separately.
Retrieve the existing send report
Use the report receipt from the original send, rather than sending the message again. Keep the origin SQS endpoint separate from the publishedt9 report endpoint:
Use the signed SDK retrieval flow to call T9CloudAdapter.GetExplanation with the receipt’s report ID and fmt: "Json". Sign for service t9 using the published T9_ENDPOINT_URL, T9_SIGNING_REGION and the same report owner’s IAM credentials, including any session token. Decode the outer AWS JSON response’s body string, parse it as JSON and save the rendered report as sqs-report.json. Then inspect its PostgreSQL facts:
minimumVersion until a positive revision exists. Export any needed evidence before acknowledgment or the fixed expiry in x-t9-explain-expires-at; reads do not renew the default 24-hour retention. See existing-report retrieval.
PostgreSQL: inspect the insert estimate
Confirm reporting scope before capture. This example concerns a Classic PostgreSQL send, statement code
sqs.message.insert and ordinal 1. It does not establish availability in every installed release or support for FIFO deduplication, batch operations or dead-letter movement. Confirm the exact operation, backend and installed capture support before requesting a plan.ModifyTable → Result tree estimates that insert. The relation name identifies a physical table, not necessarily the queue URL or origin name. Plan Rows estimates the output at each node; it does not count delivered messages. Total Cost uses PostgreSQL planner units, not milliseconds. Compare costs only for comparable statements, inputs and database contexts.
A direct values insert need not have an Index Scan or an Index Cond. That absence does not show a missing queue index or describe the later receive path. PostgreSQL receives use a different statement to select eligible rows and claim them with FOR UPDATE SKIP LOCKED; dead-letter routing adds other work. A send plan does not qualify those statements or prove that a particular message was visible to a consumer. If a separately supported statement’s plan includes an index condition, residual filter or nested scan, inspect those predicates and row estimates together rather than assuming the root node explains all work.
planningContext: "committed-state-observation" means the observer uses the actual compiled SQL and encoded parameters on a separate authenticated, read-only PostgreSQL connection. It runs EXPLAIN (FORMAT JSON) without ANALYZE; it does not insert a second message, measure execution time, or share the original send’s transaction snapshot. The native result and independently observed message or business state establish effects. A complete plan may arrive in a later report revision; unsupported context or unavailable planning capacity must remain an explicit limitation.
Service Bus and Pub/Sub: inspect broker evidence
For native Azure Service Bus, investigate the selected physical entity, send acknowledgment and later lock handling. For native Pub/Sub Classic, investigate publication, subscription delivery and acknowledgment. The authored mapping does not imply that every installed release or operation has complete Explain capture. Read recorded admission decisions, effects, observed outcomes and explicit gaps. Use the native message ID and independent broker/application observations to connect acceptance with processing. Native broker message operations do not acquire a PostgreSQL message plan merely because the install has a shared persistent control catalog. SQL-assisted FIFO is a different design with an explicitly configured SQS message authority; inspect evidence for its actual SQL and transport steps only where capture is supported. A broker acknowledgment does not prove completion or manufacture an unrecorded report fact. For full-body Pub/Sub FIFO, distinguish SQL acceptance, durable broker observation and SQS delivery. A broker outage can leave accepted messages waiting for first observation; an ordering-key byte limit includes attributes and envelope. For wakeup-only Pub/Sub or Service Bus coordination, SQL remains the body/claim authority and scans repair missing hints. Duplicate wakeups must not be counted as additional logical messages or consumer completions. For Cosmos FIFO, retain dedup scope, partition identity, lifecycle generation and the exact claim/attempt. Queue-scope and MessageGroup-scope configurations have different replay and storage consequences. Cross-partition atomic DLQ is unsupported; direct PostgreSQL atomic moves likewise require the same supported SQS-owned message database transaction. A shared server or control catalog does not make cross-store movement atomic. For the slow-worker case above, supported receive capture can recordsqs.receive.visibility-seconds, sqs.receive.visibility-source and sqs.receive.wait-seconds. These describe selected settings; sqs.receive.message-eligibility can remain unknown. A Service Bus lock that expires or is lost across an adapter restart differs from a durable PostgreSQL receipt handle. A Pub/Sub subscription’s acknowledgment behavior differs again. Compare the installed backend’s rules and actual receive/delete outcomes before deciding to retry.
Full PostgreSQL plans remain private to the exact report owner in every format. They may contain physical relation names and application values inside predicates. Sanitize a copy before sharing it, even when the message body has already been removed from the support bundle. See PostgreSQL plan interpretation and privacy.
For a support handoff, include redacted queue URL and ARN, account and Region, Standard or FIFO profile, target backend, queue attributes, message/group/dedup IDs where relevant, receive and delete times, SDK error and attempt IDs, report revision and limitations, and independent business-state observation. Remove message bodies and credentials from the shared bundle. Use Troubleshooting Explanations for missing receipts or report access failures.
A Support Agent can help correlate the queue backend, claim timeline and reviewed report without treating a duplicate delivery as permission to replay a business action.