Everything I could decide myself is decided. What's left needs
you. Each one has a recommendation from Fable — if you agree, pick it and
press Done. "I'm not sure" is a real answer and becomes work for me.
You don't need to open the session — pressing Done sends your answer back and it picks up.
1scripts/stress-common/nuke-test-data.ts purgeDLQ() issues an UNFILTERED PurgeQueueCommand against the hardcoded PRODUCTION inbound DLQ (propflow-inbound-dlq.fifo), errors swallowed by a bare catch. Called by sms-stress/cleanup.ts:69, email-stress/cleanup.ts:159 and voice-stress/cleanup.ts:67, twice per run (pre and post). Confirmed in code today: a real inbound message that hits an Anthropic 429 is retried 3x over ~12min then parks in that DLQ by design (inbound-dispatcher.ts:1548 rethrows, handler returns batchItemFailures, maxReceiveCount=3). Nothing in the repo redrives that queue automatically, so the DLQ is the last stop before permanent loss - and the stress suite purges it wholesale. In place since at least 2026-08-01, fires every nightly. Ten lines above it in the same file nukeTestPropertyTours explicitly PROTECTS non-stress rows, so the scoping discipline exists and this function simply does not use it. Not urgent tonight (DLQ reads 0, no 429s since 06:45Z) and I am NOT touching the cron. Which fix do you want?
In plain terms. Our own nightly test suites are deleting real customers' messages. When a text arrives and Clara is too busy to answer it, the system retries three times and then parks the message in a holding queue - that queue is the last thing standing between a lost text and a recovered one. Our stress tests wipe that entire queue clean, twice per run, three different suites, every single night. It has been doing this since at least the 1st of August. Nothing else empties that queue, so anything sitting in it when a test runs is simply gone, with no record of what it was. The queue is empty right now and tonight's run will most likely delete nothing, so this is not an emergency tonight - but it is a real hole and it fires again every night until it is closed. I am not changing the nightly schedule myself; that is not a call I make on my own. What I need from you is which fix you want: only delete our own test messages and leave everything else alone, or stop the wipe entirely and clean up test messages a different way. Either is a small change, but which one is your call because the wipe was presumably put there for a reason.
Fable recommends: Scope the purge: filter to the stress phone block and delete only our own messages, leaving real parked messages untouched - matches the protective pattern nukeTestPropertyTours already uses in the same file It keeps whatever the purge was actually for (stopping stress messages piling up in the DLQ) while removing the blast radius, and it mirrors a protective pattern that already exists ten lines away in the same file, so it is the smaller and more reviewable change. Dropping the purge outright is defensible but risks the accumulation problem the purge presumably exists to solve, and nobody has established what that problem was. Tried first, unsuccessfully: fa922755a - RESOLVED (held under reversal) that the right move is escalate WITHOUT touching tonight's cron: the DLQ is empty, the 429 storm ended at 06:45Z, the defect is not new (since ~2026-08-01, every nightly), DLQs are separately alarmed, and CLAUDE.md names cron schedules as the one class an agent must not change unilaterally. It did not decide WHICH fix to build - that is the question here.