diff --git a/editorial/agent-rewrites/274.json b/editorial/agent-rewrites/274.json
index 11adafb..0dc1de2 100644
--- a/editorial/agent-rewrites/274.json
+++ b/editorial/agent-rewrites/274.json
@@ -1,7 +1,7 @@
 {
   "index": 274,
   "slug": "editorial-2020-05-field-background-jobs",
-  "title": "Фоновая задача продублировала экспорт: порядок записи, ack и карантин ошибок",
-  "excerpt": "Разбираем два сбоя фонового worker: повторный внешний эффект после потери ack и бесконечный requeue для постоянной ошибки. Показываем порядок действий, журнал и критерий готовности.",
-  "contentHtml": "<p>Пользователь запускает экспорт и через несколько минут получает два одинаковых файла. В той же очереди задача с неизвестным типом отчёта появляется снова сразу после отказа worker. Первая ошибка создаёт лишний внешний эффект: приходится выяснять, какой файл считать правильным, и чистить дубликаты. Вторая забивает worker одинаковыми исключениями. Полезные задачи ждут, а журнал растёт быстрее, чем его успевает читать дежурный инженер.</p>\n<p>Тезис такой: доставка сообщения и выполнение бизнес-операции — разные факты. Broker может доставить одну бизнес-задачу повторно, если не увидел подтверждение. Worker обязан сделать повтор безопасным по устойчивому ключу. Он также обязан отличать временный сбой от постоянной ошибки входных данных. Для первой ошибки нужен идемпотентный результат и правильный порядок записи. Для второй — ограничение попыток и карантин, а не безусловный <code>requeue</code>.</p>\n<h2>Что именно повторяется</h2>\n<p>Пусть запрос создаёт задачу с <code>jobId = export-42-2020-05</code>. Producer публикует сообщение, а worker получает delivery с отдельным <code>deliveryTag</code>. Первый идентификатор относится к бизнес-операции. Второй относится к конкретной доставке на канале. Новый <code>deliveryTag</code> не означает новый экспорт.</p>\n<p>Worker начинает работу, сохраняет файл и переводит задачу в <code>succeeded</code>. Затем соединение с broker обрывается до <code>ack</code>. Для broker доставка осталась неподтверждённой. После восстановления consumer получает её снова. Если обработчик каждый раз вызывает экспорт, он создаёт второй файл. Если имя строится из текущего времени, по имени файла невозможно доказать, что это повтор.</p>\n<p>Вторая задача содержит <code>reportKind = unknown</code>. Worker не может обработать её ни сейчас, ни через секунду: причина находится во входных данных. Если обработчик на любое исключение отвечает <code>nack(requeue=true)</code>, broker снова выдаёт то же сообщение. Так возникает hot loop. Повтор помогает только тогда, когда новая попытка может изменить исход.</p>\n<figure><img src=\"/assets/editorial/2020/background-job-diagnosis-2020.svg\" alt=\"Схема диагностики фоновой задачи по jobId: запись задачи, outbox, доставка, журнал worker, результат и карантин\" /><figcaption>Проверяйте один jobId от публикации до результата. Так видно, на каком переходе возник повтор или остановилась задача.</figcaption></figure>\n<h2>Порядок подтверждения</h2>\n<p>Подтверждение не является сигналом «код вошёл в функцию». Для ручного ack оно должно означать, что consumer выполнил работу, за которую берёт ответственность. Если ack отправить до записи результата, сбой после ack может потерять работу. Если записать результат, но не сделать повтор безопасным, сбой до ack создаст дубль. Поэтому сначала фиксируют бизнес-результат, затем подтверждают delivery.</p>\n<p>Одного порядка недостаточно. Повтор должен найти тот же объект по <code>jobId</code>, прочитать terminal state и вернуть уже сохранённый результат. Внешний ключ результата тоже должен быть детерминированным: например, <code>reports/export-42-2020-05.csv</code>. Это защищает путь к файлу, но не любой внешний эффект. Email-провайдер или другой HTTP-сервис должен поддерживать собственный idempotency key либо получать вызов через отдельный надёжный протокол.</p>\n<h2>Учебный обработчик</h2>\n<p>Ниже — учебный псевдокод. Он показывает границу ответственности, но не является готовым клиентом RabbitMQ, не задаёт транзакционный API базы и не сообщает показатели production-нагрузки.</p>\n<pre><code>async function handle(delivery) {\n  const { jobId, reportKind } = delivery.payload;\n  const job = await jobs.lockById(jobId);\n\n  if (job.state === 'succeeded') {\n    await delivery.ack();\n    return job.resultKey;\n  }\n\n  if (!isKnownReport(reportKind)) {\n    await jobs.markQuarantined(jobId, {\n      reason: 'unknown_report_kind',\n      payloadVersion: delivery.payload.version,\n    });\n    await delivery.nack({ requeue: false });\n    return;\n  }\n\n  const resultKey = `reports/${jobId}.csv`;\n  await exportReport({ reportKind, resultKey });\n  await jobs.markSucceeded(jobId, resultKey);\n  await delivery.ack();\n}</code></pre>\n<p>Проверка terminal state стоит до внешнего действия. Блокировка или другой механизм защиты строки должен охватывать чтение состояния и резервирование работы. В реальной системе нужно решить, что происходит при падении между записью файла и <code>markSucceeded</code>. Обычно результат пишут во временный объект, затем атомарно публикуют его по детерминированному ключу и сохраняют состояние. Конкретный storage может потребовать иной протокол.</p>\n<p>Ветвь постоянной ошибки не вызывает экспорт и не отправляет сообщение обратно в основную очередь. Она сохраняет причину и версию входных данных до отрицательного подтверждения. Затем transport направляет сообщение в настроенный dead-letter route либо в другой согласованный карантин. Если такого маршрута нет, <code>requeue=false</code> не создаёт архив для разбора автоматически: сообщение может быть отброшено в зависимости от конфигурации.</p>\n<h2>Симптом → причина → проверка → действие</h2>\n<table><thead><tr><th>Симптом</th><th>Причина</th><th>Проверка</th><th>Действие</th></tr></thead><tbody><tr><td>Для одного jobId появились два файла</td><td>Результат создаётся по случайному имени или проверка состояния стоит после эффекта</td><td>Сопоставить jobId, resultKey, порядок <code>result_saved</code>, <code>succeeded</code> и <code>ack_sent</code></td><td>Читать terminal state до экспорта и сохранять результат по детерминированному ключу</td></tr><tr><td>Повторная доставка приходит после успешной записи</td><td>Соединение оборвалось до ack</td><td>Сверить журнал broker, delivery tag и запись задачи</td><td>Обработать повтор как тот же jobId, не запускать внешний эффект снова</td></tr><tr><td>attempt растёт с одной и той же причиной</td><td>Постоянную ошибку приняли за временную</td><td>Сравнить payload и код причины на соседних попытках</td><td>Сохранить причину, перевести задачу в <code>quarantined</code>, отключить requeue</td></tr><tr><td>После nack сообщение исчезло</td><td>Для очереди не настроен dead-letter маршрут или сообщение не должно храниться</td><td>Проверить policy, binding, routing key и журнал публикации</td><td>Настроить проверяемый карантин либо явно принять потерю как контракт</td></tr><tr><td>Задача долго стоит в очереди</td><td>Не сработал outbox, producer публикует не туда или worker не читает binding</td><td>Найти запись job, marker публикации и факт первой доставки</td><td>Проверить dispatcher и маршрут до handler; не менять handler без delivery</td></tr></tbody></table>\n<p>Таблица задаёт порядок расследования. Сначала привяжите наблюдение к одному <code>jobId</code>. Не начинайте с увеличения timeout или числа retry. Эти изменения не исправят случайное имя результата, неизвестный <code>reportKind</code> или неверный binding.</p>\n<h2>Почему ack не даёт exactly-once</h2>\n<p>Ручное подтверждение помогает выбрать границу ответственности, но не превращает распределённую систему в exactly-once механизм. Между записью результата и ack остаётся окно сбоя. Между отправкой ack и получением его broker тоже есть сеть. Система с повторной доставкой обычно даёт at-least-once обработку: сообщение могут обработать снова, поэтому handler должен быть идемпотентным.</p>\n<p>Признак <code>redelivered</code> полезен для диагностики, но он не заменяет бизнес-ключ. При повторной публикации похожее сообщение может выглядеть как новая доставка. Бизнес-правило должно опираться на <code>jobId</code>, уникальный ключ результата и состояние операции. Если worker выполняют несколько экземпляров, lock и уникальное ограничение должны защищать одну и ту же область.</p>\n<p>Для временной ошибки используйте ограниченный retry с задержкой. Временной может быть недоступность хранилища, краткий сетевой отказ или ещё не созданная зависимая запись. Сохраняйте <code>attempt</code>, код причины и время следующей попытки. После лимита не отправляйте сообщение в бесконечный цикл. Оставьте его в карантине, чтобы инженер мог исправить данные или код и принять решение о повторном запуске.</p>\n<h2>Порядок действий</h2>\n<ol><li>Выберите один повторившийся или застрявший <code>jobId</code>. Соберите запись задачи, payload, outbox, delivery и журнал worker в одной временной шкале.</li><li>Разделите идентификаторы: бизнес-ключ операции, delivery tag, attempt и ключ внешнего результата. Не считайте новый delivery новой операцией.</li><li>Проверьте порядок переходов. Зафиксируйте, когда появились <code>result_saved</code>, terminal state и <code>ack_sent</code>. Не запускайте экспорт повторно, пока не проверили сохранённый результат.</li><li>Проверьте идемпотентность: повторная доставка того же jobId должна прочитать terminal state и завершиться без нового файла, письма или внешнего вызова.</li><li>Классифицируйте ошибку. Если вход невалиден или тип неизвестен, сохраните постоянную причину и не делайте requeue. Если зависимость может восстановиться, задайте конечный лимит и задержку.</li><li>Проверьте карантин на выбранном broker: policy, exchange, binding, routing key и права публикации. Отрицательное подтверждение без проверенного маршрута не считается обработанным исходом.</li><li>Проверьте отрицательный путь на интеграционном стенде: оборвите соединение после записи результата и до ack, затем подайте повтор. Отдельно отправьте невалидный payload и убедитесь, что после лимита он перестаёт возвращаться в основную очередь.</li><li>Добавьте наблюдаемость: jobId, attempt, delivery tag, event, resultKey, reason и длительность. Не записывайте в журнал секреты и полное содержимое пользовательского отчёта.</li></ol>\n<h2>Ограничения</h2>\n<p>Описанный алгоритм не говорит, какая база или очередь нужна проекту. Row lock защищает только выбранную запись и не заменяет уникальное ограничение во внешнем хранилище. Состояние в базе и файл в object storage не откатываются одной транзакцией. Если процесс остановился после загрузки файла, нужна проверка существующего ключа и политика очистки незавершённых объектов.</p>\n<p>Лимит retry нельзя выбрать одинаковым для всех задач. Слишком малый лимит превращает краткий сбой в карантин. Слишком большой растягивает задержку и маскирует постоянную ошибку. Backoff и лимит должны учитывать стоимость работы, срок жизни входных данных и допустимую задержку пользователя.</p>\n<p>Учебный код не доказывает поведение конкретной версии broker, client library или policy. Проверяйте ack, redelivery, nack, dead-lettering и восстановление соединения на той конфигурации, которую действительно запускает сервис. Не называйте результат готовым, если проверили только in-memory переходы.</p>\n<h2>Критерий готовности</h2>\n<p>Решение готово, когда два независимых сценария проходят на выбранном окружении. После сбоя между сохранением результата и ack повторная доставка того же <code>jobId</code> не создаёт второй внешний эффект и возвращает один проверяемый <code>resultKey</code>. После постоянной ошибки payload задача достигает <code>quarantined</code> не позднее заданного лимита, причина сохраняется, а сообщение не возвращается в основную очередь. В журнале можно восстановить порядок событий без догадок.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href=\"https://www.rabbitmq.com/docs/reliability\" target=\"_blank\" rel=\"noopener\">RabbitMQ: Reliability Guide</a> — ответственность producer и consumer, acknowledgements, повторная передача и at-least-once доставка.</li><li><a href=\"https://www.rabbitmq.com/docs/next/confirms\" target=\"_blank\" rel=\"noopener\">RabbitMQ: Consumer Acknowledgements and Publisher Confirms</a> — семантика consumer ack, requeue и восстановление неподтверждённых delivery.</li><li><a href=\"https://www.rabbitmq.com/docs/next/dlx\" target=\"_blank\" rel=\"noopener\">RabbitMQ: Dead Letter Exchanges</a> — условия dead-lettering и настройка маршрута для сообщений, которые нельзя возвращать в основную очередь.</li></ul>"
+  "title": "Разбор: почему экспорт отчёта повторился и как остановить poison message",
+  "excerpt": "Учебный разбор двух путей: результат создан до потерянного ack и невалидная задача крутится в requeue. Собираем журнал, меняем порядок и вводим карантин.",
+  "contentHtml": "<p>Симптом в учебном разборе такой: пользователь запрашивает экспорт, а через несколько минут видит два одинаковых файла. Одновременно другая заявка с неизвестным типом отчёта снова и снова появляется у worker, занимая очередь. Цена двойная. Первый сбой создаёт лишний внешний эффект и спор, какая копия верная; второй забирает время worker и скрывает полезные задачи под повторяющейся ошибкой. Фраза «очередь доставила дважды» описывает факт, но ещё не называет место, где принято неверное решение.</p>\n<p>Разберу не production-инцидент, а анонимизированную in-memory фикстуру мая 2020 года. В ней нет реального broker, файлового хранилища, user data или измеренной нагрузки. Зато есть две детерминированные цепочки с одним <code>jobId</code> каждая: временный отказ между сохранением результата и ack, а также невалидный payload после лимита попыток. Цель — показать практическое расследование: симптом → причина → проверка → действие, а не рассказать историю успеха постфактум.</p>\n<h2>Сначала отделяем факт результата от факта delivery</h2>\n<p>Первый экспорт имеет <code>jobId = export-42-2020-05</code>. Worker получил delivery, записал CSV по устойчивому ключу и пометил задачу как <code>succeeded</code>. Затем соединение до broker оборвалось до ack. У broker остаётся непроверенное delivery, поэтому следующий worker получает ту же бизнес-задачу повторно. Если handler относится к любому received message как к новому, он снова вызывает экспорт и пишет второй файл с новым случайным именем. Это не исправляется большим timeout: проблема в том, что idempotency check находится после эффекта или отсутствует.</p>\n<p>Вторая заявка — <code>export-43-2020-05</code> — содержит неизвестный <code>reportKind</code>. Worker ловит ошибку, делает <code>nack(requeue=true)</code> и тут же получает ту же доставку снова. Никакая пауза не сделает неизвестный тип валидным. Пока задача не имеет состояния <code>quarantined</code> и ограничителя попыток, очередь по сути работает как генератор одинаковых ошибок. Здесь цена уже операционная: журнал растёт, полезная работа ждёт, а владелец данных не получает короткий список того, что нужно исправить.</p>\n<pre><code>{&quot;event&quot;:&quot;received&quot;,&quot;jobId&quot;:&quot;export-43-2020-05&quot;,&quot;attempt&quot;:3,&quot;redelivered&quot;:true}\n{&quot;event&quot;:&quot;validation_failed&quot;,&quot;jobId&quot;:&quot;export-43-2020-05&quot;,&quot;reason&quot;:&quot;unknown_report_kind&quot;}\n{&quot;event&quot;:&quot;quarantined&quot;,&quot;jobId&quot;:&quot;export-43-2020-05&quot;,&quot;queue&quot;:&quot;jobs.quarantine&quot;}\n{&quot;event&quot;:&quot;nack_sent&quot;,&quot;jobId&quot;:&quot;export-43-2020-05&quot;,&quot;requeue&quot;:false}</code></pre>\n<p>Строки выше — синтетический журнал фикстуры, не вывод запущенного RabbitMQ consumer. Они важны именно порядком. У poison-задачи третья попытка ещё фиксирует вход и причину, затем приложение сохраняет <code>quarantined</code>, и только после этого выбранному transport посылается отрицательный ответ без requeue. В реальном AMQP дальнейшая судьба зависит от настроенного dead-letter exchange: без маршрута сообщение может быть отброшено. Поэтому «карантин» обязан существовать не только как слово в коде, но и как проверяемая конфигурация выбранного окружения.</p>\n<div class=\"table-scroll\"><table><caption>Карта расследования: какой факт исключает какую гипотезу</caption><thead><tr><th scope=\"col\">Наблюдение</th><th scope=\"col\">Причина, которую проверяем</th><th scope=\"col\">Минимальное доказательство</th><th scope=\"col\">Действие</th></tr></thead><tbody><tr><td>Есть resultKey, но нет ack_sent</td><td>сбой произошёл в узком окне после результата</td><td>job.state = succeeded раньше следующего received</td><td>при повторе не создавать результат, подтвердить новое delivery</td></tr><tr><td>Два файла для одного jobId</td><td>внешний эффект не имеет стабильного ключа либо check сделан поздно</td><td>сопоставить имена файлов и порядок journal</td><td>путь результата построить из jobId, terminal state читать до export</td></tr><tr><td>attempt растёт, причина одна и та же</td><td>постоянный payload повторно requeue</td><td>validation_failed повторяется на равных входных данных</td><td>пометить quarantined и направить в DLX/разбор</td></tr><tr><td>queued долго без received</td><td>outbox не опубликован либо worker не читает маршрут</td><td>есть job/outbox, но нет publish marker и journal delivery</td><td>проверить dispatcher, binding и конкретный broker client</td></tr></tbody></table></div>\n<p>Эта таблица не заменяет доступ к очереди. Она задаёт порядок вопросов до изменения кода. Если уже есть <code>resultKey</code>, не нужно стартовать новый экспорт «на всякий случай». Если причина <code>unknown_report_kind</code> воспроизводится из сохранённой версии payload, не нужно увеличивать retry. Если у задачи нет <code>received</code>, бесполезно рассматривать handler: сперва ищем outbox, публикацию и маршрут. Каждый шаг привязывает действие к одному наблюдаемому факту.</p>\n<figure><img src=\"/assets/editorial/2020/background-job-diagnosis-2020.svg\" alt=\"Вертикальная схема диагностики фоновой задачи: по jobId проверяют запись задачи, outbox и сообщение, затем журнал worker, сохранённый resultKey и при постоянной ошибке карантинную очередь\" loading=\"lazy\" /><figcaption>Разбор идёт не по названию компонента, а по пути одного jobId. Это уменьшает риск перезапустить эффект, когда проблема находится до worker или после результата.</figcaption></figure>\n<h2>Причина первого дубля: случайное имя и ack не на той стороне</h2>\n<p>Плохой вариант handler выглядит почти естественно: он берёт сообщение, сразу начинает генерацию, формирует имя из текущего времени, отправляет ack и только затем пытается отметить успех. В нём две точки неопределённости. Во-первых, повтору нечем доказать, что прежняя генерация уже завершилась: название файла другое, а состояние ещё не terminal. Во-вторых, ack может добраться до broker раньше записи статуса. При сбое получаем либо потерянную работу, либо повтор без защиты.</p>\n<p>Исправление на уровне одной задачи не требует общего дедупликатора. Worker сначала читает строку по <code>jobId</code> с блокировкой, проверяет terminal states и резервирует попытку. Результат записывается по детерминированному ключу <code>reports/{jobId}.csv</code>. После записи в этом же бизнес-шаге сохраняются <code>resultKey</code> и <code>succeeded</code>. Если после этого broker повторно доставит сообщение, handler видит terminal state, не пишет файл заново и только завершает текущий delivery. Для email или внешнего API нужно отдельно убедиться, что принимающая сторона поддерживает такой ключ; путь файла не решает чужой side effect.</p>\n<div class=\"table-scroll\"><table><caption>Изменение порядка для повторной доставки</caption><thead><tr><th scope=\"col\">Старая последовательность</th><th scope=\"col\">Риск</th><th scope=\"col\">Новая последовательность</th><th scope=\"col\">Проверяемый результат</th></tr></thead><tbody><tr><td>receive → generate random file → ack → save state</td><td>дубль или потеря при падении между шагами</td><td>receive → read job → save deterministic result + succeeded → ack</td><td>повтор видит succeeded и не создаёт второй файл</td></tr><tr><td>catch → nack(requeue=true) всегда</td><td>горячий цикл на невалидном payload</td><td>classify → retry_wait или quarantined → nack по решению</td><td>attempt ограничен, причина остаётся рядом с jobId</td></tr><tr><td>искать ошибку по времени</td><td>непонятно, к какой попытке относится строка</td><td>писать jobId, attempt, event, reason</td><td>одна цепочка читается без догадки о совпадении</td></tr></tbody></table></div>\n<p>Здесь нет обещания, что SQL-блокировка сделает worker глобально одиночным. Она лишь защищает запись задачи в границе выбранной базы. Конкурирующие worker, внешнее хранилище и сеть всё равно требуют проверяемого контракта. Поэтому практический критерий короче: каждый новый delivery для уже <code>succeeded</code> обязан завершиться без нового результата. Если это нельзя проверить, слово «идемпотентность» в код-ревью пока ничего не означает.</p>\n<h2>Причина hot loop: постоянную ошибку приняли за временную</h2>\n<p>Повтор нужен, когда новое время может изменить исход: зависимость была недоступна, лимит снят, ожидаемая запись ещё не появилась. Но <code>unknown_report_kind</code> не зависит от времени. Для такого случая worker должен назвать ошибку постоянной, сохранить её в записи и завершить автоматический путь. В AMQP отрицательный ответ без requeue может направить сообщение в DLX, если проект это настроил. Отдельный маршрут делает ошибку предметом разбора, а не бесконечным consumer workload.</p>\n<p>Карантин не стоит использовать как корзину для всех исключений. Сначала сохраняем тип причины и версию payload: это отделяет неисправимые данные от дефекта worker после обновления. Затем владелец решает: поправить данные и переиздать новую задачу с новым или тем же бизнес-ключом, починить consumer и вручную вернуть сообщение через контролируемый маршрут, либо отменить операцию. Автоматическое чтение карантина обратно в основную очередь без исправления причины снова создаёт тот же loop, только с более длинным названием.</p>\n<h2>Фикстура как маленький регрессионный контракт</h2>\n<p>В модуле ревизий есть команда <code>node scripts/upgrade-2020-05.mjs --verify-fixture</code>. Она не эмулирует AMQP frames. Она детерминированно создаёт две записи в памяти: первая переживает transient ошибку, получает повторную доставку, сохраняет result и ack; вторая после третьего неуспеха переходит в <code>quarantined</code>. Вывод — JSON-журнал и три булевых условия. Такой тест полезен тем, что не позволяет незаметно переставить <code>result_saved</code> и <code>ack_sent</code> в учебном алгоритме.</p>\n<pre><code>{&quot;event&quot;:&quot;received&quot;,&quot;jobId&quot;:&quot;export-42-2020-05&quot;,&quot;attempt&quot;:1,&quot;redelivered&quot;:false}\n{&quot;event&quot;:&quot;retry_scheduled&quot;,&quot;jobId&quot;:&quot;export-42-2020-05&quot;,&quot;attempt&quot;:1,&quot;reason&quot;:&quot;upstream_timeout&quot;}\n{&quot;event&quot;:&quot;received&quot;,&quot;jobId&quot;:&quot;export-42-2020-05&quot;,&quot;attempt&quot;:2,&quot;redelivered&quot;:true}\n{&quot;event&quot;:&quot;result_saved&quot;,&quot;jobId&quot;:&quot;export-42-2020-05&quot;,&quot;resultKey&quot;:&quot;reports/export-42-2020-05.csv&quot;}\n{&quot;event&quot;:&quot;ack_sent&quot;,&quot;jobId&quot;:&quot;export-42-2020-05&quot;,&quot;attempt&quot;:2}</code></pre>\n<p>Фикстура не даёт ложной уверенности в broker. У неё нет TCP-соединения, реального delivery tag, политики DLX, нескольких consumer или диска. Но она отделяет две логические проверки, которые можно выполнить без инфраструктуры: для retry есть новая попытка с тем же jobId, а успешный путь пишет result до ack; poison-путь обрывает requeue на известном пределе. После выбора библиотеки эту же пару сценариев нужно повторить на интеграционном стенде и сравнить реальные журналы с ожидаемыми переходами.</p>\n<h2>Маршрут разбора перед исправлением</h2>\n<ol><li>Взять один конкретный jobId и собрать рядом запись задачи, outbox, журнал worker, ключ результата и информацию о current attempt.</li><li>Проверить, в каком порядке появились result_saved, succeeded и ack_sent; не делать новый экспорт, пока это не ясно.</li><li>Для повтора сравнить jobId, а не delivery tag: новый tag не означает новую бизнес-операцию.</li><li>Классифицировать последнюю ошибку как временную, неопределённую внешнюю или постоянную; записать основание рядом с attempt.</li><li>Для постоянной ошибки остановить requeue, перевести job в quarantined и проверить, что выбранная DLX/карантинная поверхность действительно принимает сообщение.</li><li>После изменения прогнать in-memory фикстуру, затем отдельный broker-интеграционный сценарий с падением до ack; в этом пакете выполнен только первый шаг.</li></ol>\n<h2>Граница полевого разбора</h2>\n<p>Все идентификаторы, причины и строки журнала здесь придуманы для проверки переходов. Нет реального файла, заказчика, очереди, RabbitMQ policy, production-config или browser-действия. Тексты опираются на спецификацию AMQP и официальную документацию RabbitMQ, чтобы не выдумывать смысл ack, reject и redelivery, но не выдают современную документацию за снимок конкретной инфраструктуры мая 2020 года. Автор этого периода умеет провести узкое backend/delivery расследование и оставить route для стенда; он ещё не заявляет готовую платформу наблюдаемости или сложную оркестрацию.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href=\"https://www.rabbitmq.com/resources/specs/amqp-xml-doc0-9-1.pdf\" target=\"_blank\" rel=\"noopener noreferrer\">AMQP 0-9-1 specification: basic.ack и basic.reject</a> — первичная спецификация: delivery tag адресует доставку, а basic.reject с requeue управляет возвратом или отказом от сообщения</li><li><a href=\"https://www.rabbitmq.com/docs/confirms\" target=\"_blank\" rel=\"noopener noreferrer\">RabbitMQ: Consumer Acknowledgements and Publisher Confirms</a> — официальное описание ручного ack, автоматического requeue не подтверждённой доставки и риска немедленного redelivery loop</li><li><a href=\"https://www.rabbitmq.com/docs/reliability\" target=\"_blank\" rel=\"noopener noreferrer\">RabbitMQ: Reliability guide</a> — официальная граница между подтверждением доставки и обработкой, а также необходимость идемпотентного consumer при повторной доставке</li><li><a href=\"https://www.rabbitmq.com/docs/dlx\" target=\"_blank\" rel=\"noopener noreferrer\">RabbitMQ: Dead Letter Exchanges</a> — официальное описание маршрутизации отклонённого сообщения в отдельный exchange и причин dead-lettering</li></ul>"
 }