# Dead Letter Queue／Poison Task運用

CURRENT_STATUS: CURRENT
OBSERVATION: SPEC_ONLY
FRESHNESS: CURRENT
PAGE_TYPE: reference
CANONICAL_URL: /tools/ea-245-dead-letter-queue-poison-task
CLAIM_IDS: none
EVIDENCE_IDS: EA-245-CURRENT-APPROVAL, EA-245-CURRENT-BODY-READBACK
UNKNOWN_IDS: EA-245-UNKNOWN-01
OPS_IDS: none

## Summary
Dead Letter Queue（DLQ）は、繰り返し失敗するmessage/taskを通常処理から隔離するための運用境界です。DLQへ移動したこと自体は、root causeの修復、messageの永久保存、外部side effectのexactly-onceを意味しません。

## Current judgment
Dead Letter Queue（DLQ）は、繰り返し失敗するmessage/taskを通常処理から隔離するための運用境界です。DLQへ移動したこと自体は、root causeの修復、messageの永久保存、外部side effectのexactly-onceを意味しません。

## Scope
Dead Letter Queue／Poison Task運用

## Confirmed

## UNKNOWN
- EA-245-UNKNOWN-01: 対象broker/runtime、queue type/version、retry budget、DLQ topology、IAM/KMS、retention、ordering/session、task schema、model/tool/policy versions、side-effect status API、redrive authority、alert/SLO、data classification/residency、disposal evidenceは未確認です。

## Evidence
- EA-245-CURRENT-APPROVAL (RESEARCH): 現行本文の監査・revision対応
- EA-245-CURRENT-BODY-READBACK (IMPL): 現行本文の収録照合

## Failure / limits
少なくともfailureを次へ分けます。
## Failure / limits
transient/retryable: timeout、429、一時5xx、短期provider outage等
## Failure / limits
deterministic/non-retryable: schema invalid、unsupported tool version、明示的policy denial等
## Failure / limits
authorization/configuration: credential失効、permission不足、KMS/IAM不整合
## Failure / limits
ambiguous external outcome: tool/APIが成功した可能性があるがack/response/checkpointを失った状態
## Failure / limits
unknown: 根拠なくretryableへ分類しない


retry budgetを超えたtransient failureと、即時隔離すべきdeterministic failureを区別します。
## Failure / limits
poison input、schema error、malformed model/tool output、policy denial、credential失効、permission loss、provider outage、consumer bug、code/schema drift、stale resource、ambiguous external outcome、duplicate delivery、attempt counter ambiguity、retry storm、DLQ publish failure、missing subscription、retention expiry、PII/secret leakage、wrong redrive、ordering break、cycle、manual deletion without auditを想定します。
## Failure / limits
attempt count・retention・dead-letter forwarding safetyを一般化せず、Agent poison taskのquarantine、triage、redrive gate、external side-effect reconciliationを監査可能な運用境界として固定します。
## Practice
DLQは失敗prompt、tool arguments、customer payload、error traceを蓄積するため、高感度archiveになり得ます。


least privilege、encryption、KMS/IAM、tenant isolation、redaction、retention、data residency、削除証跡を通常queueと別に確認します。redrive authorityを通常consumer権限へ無条件に含めません。
## Practice
本項は2026-10-05時点のAmazon SQS、Azure Service Bus、Google Cloud Pub/Sub、Kafka Connect、RabbitMQの現行documentationとbounded local fixtureに基づきます。production queue、Agent task、external side effectのmutation/redriveは未実施です。
## PUBLIC_CLAIM
Dead Letter Queue（DLQ）は、繰り返し失敗するmessage/taskを通常処理から隔離するための運用境界です。DLQへ移動したこと自体は、root causeの修復、messageの永久保存、外部side effectのexactly-onceを意味しません。


AI/Agentでは、LLM/provider障害、schema drift、tool/API変更、policy denial、権限、stale resource、deterministic bad inputを同じblind retryへ入れないことが重要です。

## FAILURE_CLASSIFICATION
少なくともfailureを次へ分けます。


- transient/retryable: timeout、429、一時5xx、短期provider outage等
- deterministic/non-retryable: schema invalid、unsupported tool version、明示的policy denial等
- authorization/configuration: credential失効、permission不足、KMS/IAM不整合
- ambiguous external outcome: tool/APIが成功した可能性があるがack/response/checkpointを失った状態
- unknown: 根拠なくretryableへ分類しない


retry budgetを超えたtransient failureと、即時隔離すべきdeterministic failureを区別します。

## ATTEMPT_SEMANTICS
delivery/receive countの意味をcross-provider invariantとして扱いません。


Google Cloud Pub/Subのmaximum delivery attemptsはbest-effortであり、設定値どおりの厳密な境界とは限りません。


Amazon SQS、Azure Service Bus、Pub/Sub等でattempt counting、TTL、redrive条件が異なるため、対象product/queue type/versionのdocumented semanticsを固定します。

## QUARANTINE_ENVELOPE
DLQ/quarantine recordには可能な範囲で以下を保持します。


- original task/message ID
- workflow/run ID
- tenant/principal
- input hashとschema/version
- model/provider ID
- prompt/tool/schema/policy version
- attempt count
- first/last failure timestamp
- normalized failure class/reason
- raw errorの安全なlocator
- external operation ID/idempotency key
- last known authoritative external state
- remediation owner/status


secret tokenや不要なPIIをerror descriptionへ複製しません。

## PRODUCT_BOUNDARIES
Amazon SQSではsource queueのredrive policyとDLQ側redrive allow policyを区別します。DLQ redriveにはSQS操作権限に加え、暗号化構成によってKMS権限が必要です。Standard/FIFOではDLQ移動後のtimestamp/retention semanticsも異なります。


Azure Service Busでは通常のDLQとtransfer dead-letter queueを区別します。consumer processing failureとforwarding infrastructure failureを同一reasonへ潰しません。DLQは自動cleanupされず、明示的な処理まで残ります。


Google Cloud Pub/Subではdead-letter topicの設定だけでなく、service accountのpublish/ack権限とdead-letter topic側subscriptionを確認します。maximum delivery attemptsはbest-effortです。


Kafka Connectでは`errors.tolerance=all`で処理継続できても、failed recordの存在が消えるわけではありません。DLQとmetricsを監視し、欠落をsilent successとして扱いません。


RabbitMQではdead-letter exchangeへのrepublish自体が失敗し得ます。queue typeとpublisher-confirm semanticsを確認し、DLXをlossless archiveと仮定しません。

## REDRIVE_GATE
redrive前に少なくとも次を確認します。


1. root causeが特定されているか。
2. consumer/tool/schema/policy/codeの修正版が配備されているか。
3. credential/IAM/KMS/configurationが回復しているか。
4. original taskが対象としたresource version/preconditionがまだ有効か。
5. external side effectが既に成功していないかauthoritative readbackできるか。
6. stable idempotency key/operation IDを維持できるか。
7. redrive destination、batch size、concurrency、ordering影響が許容されるか。
8. 再失敗時のre-dead-letterと停止条件があるか。


root cause未修正のmass redriveを行いません。

## SIDE_EFFECT_RECONCILIATION
timeoutやworker crashでは、外部tool/APIが成功した後にconsumer側が失敗と認識する場合があります。


この状態を単純にredriveするとduplicate side effectを作り得ます。redrive前にexternal operation ID、idempotency key、resource state/versionを照合し、既済みなら再実行せずworkflow stateをreconcileします。

## RETENTION_AND_DISPOSAL
DLQ retentionを“隔離後N日”と一般化しません。製品・queue type固有のtimestamp/TTL semanticsを確認します。


DLQ depthだけでなくoldest ageとretention expiry riskを監視し、期限前にtriageします。修復不能または不要になったtaskは、削除理由、operator、evidence locator、最終状態を記録してdispositionします。

## SECURITY_AND_PRIVACY
DLQは失敗prompt、tool arguments、customer payload、error traceを蓄積するため、高感度archiveになり得ます。


least privilege、encryption、KMS/IAM、tenant isolation、redaction、retention、data residency、削除証跡を通常queueと別に確認します。redrive authorityを通常consumer権限へ無条件に含めません。

## OPERATING_CHECK
少なくとも、deterministic poison input、transient retry exhaustion、external success/ack loss、DLQ publish failure、missing DLQ subscription、IAM/KMS denial、retention expiry、wrong redrive destination、concurrent redrive、re-dead-letter loopをfault injectionします。


DLQ depth/rate/oldest age、failure class、retry amplification、redrive success、re-dead-letter rate、retention risk、operator response timeを監視します。

## FAILURE_ENVELOPE
poison input、schema error、malformed model/tool output、policy denial、credential失効、permission loss、provider outage、consumer bug、code/schema drift、stale resource、ambiguous external outcome、duplicate delivery、attempt counter ambiguity、retry storm、DLQ publish failure、missing subscription、retention expiry、PII/secret leakage、wrong redrive、ordering break、cycle、manual deletion without auditを想定します。

## IMPLEMENTATION_STATE
本項は2026-10-05時点のAmazon SQS、Azure Service Bus、Google Cloud Pub/Sub、Kafka Connect、RabbitMQの現行documentationとbounded local fixtureに基づきます。production queue、Agent task、external side effectのmutation/redriveは未実施です。

## SAFE_WORDING
DLQは失敗message/taskを隔離する運用境界であり、失敗原因の修復やside effectのexactly-onceを自動保証しません。delivery-attempt semantics、retention、dead-letter forwarding、IAM/KMSは製品ごとに異なります。redrive前にroot causeの修正、version/precondition、既済みside effectのreadback/reconciliationを確認し、stable idempotency identityを維持してください。

## OPEN_UNKNOWN
対象broker/runtime、queue type/version、retry budget、DLQ topology、IAM/KMS、retention、ordering/session、task schema、model/tool/policy versions、side-effect status API、redrive authority、alert/SLO、data classification/residency、disposal evidenceは未確認です。

## STOP_CONDITION
attempt count・retention・dead-letter forwarding safetyを一般化せず、Agent poison taskのquarantine、triage、redrive gate、external side-effect reconciliationを監査可能な運用境界として固定します。

NEXT: /agent/start.json
STOP: This is a knowledge projection, not an execution order.