Reconcile four retained failure queues after a successful replacement deploy

[alexeygrigorev]

Reconcile four retained failure queues after a successful replacement deploy

Status: blocked — awaiting #136 successful replacement deployment, then authorized HUMAN read-only reconciliation; evidence collection only
Tags: bug, infra, testing, P1
Depends on: #130 and #140 completed; #136 successful final deployment after #143 ownership remediation; #141 is not a blocker
Blocks: None
Next owner: On-Call to complete #136 deployment, then the authorized HUMAN queue-reconciliation owner
Resume condition: sanitized evidence that #136 reached terminal-success normal deployment and records the exact active replacement queue identities needed for the two separated read-only checks
Evidence: #128 On-Call retained-resource report

Exact retained inventory

Two failed deployment attempts left four generated-name queues outside the restored stack:

• dataops-v1-ConversationalExecutionFailureQueue-5tIXadG96UPw
• dataops-v1-ConversationalExecutionFailureQueue-uaUHwrRVO3KW
• dataops-v1-SponsorCommunicationFailureQueue-8iVYd6AmknFS
• dataops-v1-SponsorCommunicationFailureQueue-wtudxiKwXhgF

Initial read-only evidence found every queue at approximate available/in-flight/delayed 0/0/0, 14-day retention, no queue or redrive policy, no Lambda event-source mapping, and no current stack ownership. Sponsor queues use alias/aws/sqs; conversational queues use SQS-managed encryption.

This issue records a later reconciliation gate only. It does not authorize deletion, purge, policy changes, redrive, message receive, encryption changes, or any other queue mutation.

Acceptance Criteria

• [HUMAN] First obtain a successful Migrate Sponsor CRM GSIs in a protected stage-only workflow #136 application deployment and terminal stack success. Record the exact active replacement failure-queue physical names/ARNs/URLs from the current stack and prove none equals an old queue.
• [HUMAN] Resolve only the four exact old queue names above—never a prefix, wildcard, search result, or inferred URL—and record sanitized ARN/name hashes plus creation timestamps.
• [HUMAN] For each old queue, perform two read-only checks separated by at least that queue's configured visibility timeout. Both checks must show available/in-flight/delayed 0/0/0.
• [HUMAN] Both checks prove no queue policy, redrive policy, redrive-allow relationship, Lambda event-source mapping, EventBridge Pipe/target, SNS subscription, current CloudFormation stack reference, or active application configuration reference.
• [HUMAN] Verify retention and encryption remain as observed and compare exact old identities against the active replacement queues. Do not inspect/log message bodies or expose queue URLs, account IDs, policies, tags, or private metadata publicly.
• [HUMAN] Attach a sanitized read-only reconciliation report with timestamps, visibility-timeout separation, exact checks performed, terminal deployment reference, and reviewer verdict.
• Stop after evidence collection. Any later deletion requires explicit new authorization or regrooming with a separately reviewed exact-resource deletion/rollback plan. This issue currently grants none.

Failure handling

Any message count, ownership/reference, policy, redrive relation, mapping/target/subscription, identity ambiguity, missing active replacement, non-terminal stack, or inconsistent observation blocks reconciliation. Do not purge, move, receive, redrive, detach, retag, or delete anything to make a check pass.

Out of scope

Prefix/glob cleanup, deletion or purge, application deployment, GSI migration, IAM edits, provider/Telegram calls, message-body inspection, active replacement queue changes, or cleanup of any resource not named exactly above.

[alexeygrigorev]

PM RECORDED — blocked HUMAN reconciliation, no deletion authority

This issue preserves the four exact retained queue identities and the required two-pass read-only evidence after a successful replacement deployment. It explicitly stops after reconciliation. No delete, purge, receive, redrive, policy, encryption, tag, or other queue mutation is authorized.

[alexeygrigorev]

PM STATUS RECONCILIATION — prerequisite repair complete; read-only evidence still pending

• Repair dispatcher generated-role IAM prefix for CloudFormation rollback #130 is complete: its accepted dispatcher role-prefix repair is integrated, effective, and received PM live acceptance. It is no longer an open dependency.
• Migrate Sponsor CRM GSIs in a protected stage-only workflow #136 has not completed a successful replacement application deployment. Therefore active replacement queue identities are not yet available and none of Reconcile four retained failure queues after a successful replacement deploy #137's seven evidence criteria can begin.
• After Migrate Sponsor CRM GSIs in a protected stage-only workflow #136 succeeds, a HUMAN performs only the two-pass read-only reconciliation defined here.

PM decision: keep every acceptance criterion unchecked and retain human.
This issue authorizes evidence collection only. It does not authorize receive,
purge, redrive, delete, retag, policy/encryption changes, queue cleanup, message
inspection, or any other mutation. Any deletion remains a separately reviewed
future decision.

No code, AWS, IAM, workflow, environment, flag, provider, or queue action was
performed during this reconciliation.

[alexeygrigorev]

PM tracker reconciliation — queue evidence gate remains downstream

The issue remains read-only evidence collection only after #136 terminal deployment. Replaced the stale #141 chain with #140 lifecycle acceptance plus #143 ownership remediation, added the exact On-Call→authorized-HUMAN owner sequence and replacement-identity resume signal, normalized Blocks: None, and removed the premature human label until deployment succeeds. No queue read, receive, mutation, deletion, or criterion completion occurred.