{"index":197,"slug":"editorial-2022-07-mechanism-poor-network","title":"Плохая сеть: как не потерять черновик после повтора","excerpt":"Запрос может уйти, а подтверждение — не прийти. Разбираем неизвестный исход, разделяем версию черновика, логическую операцию и попытку, а затем проверяем поздние ответы и безопасный повтор.","contentHtml":"<p>Пользователь нажимает «Сохранить». Кнопка перестаёт крутиться, но экран не знает, дошёл ли запрос до сервера. Человек нажимает ещё раз. Пока второй запрос ждёт ответа, приходит первый. Если обработчик связывает ответ только с формой, он может закрыть редактор, очистить новый текст или показать успех для операции, которую никто не подтвердил. Цена ошибки — потерянная работа, дублирующее изменение на сервере и расследование по одному скриншоту без доказательств.</p>\n<p>Плохая сеть не означает только медленный канал. Запрос может завершиться на сервере, но ответ потеряется. Ответ может прийти позже нового ввода. Браузер может сообщить об ошибке транспорта, хотя предметная операция уже изменила данные. Поэтому «нет ответа» не равно «операция не выполнена».</p>\n<p>Тезис статьи: интерфейс должен хранить отдельно версию черновика, логическую операцию и конкретную попытку. Состояние <code>unknown-outcome</code> должно быть видимым. Повтор разрешается только по явному правилу. Поздний ответ меняет экран только после проверки ключей и версии. Этот механизм защищает локальный текст; он не доказывает результат на сервере без согласованного API.</p>\n<h2>Сначала разделите четыре состояния</h2>\n<p><code>draft.version</code> — версия текста, которую редактирует пользователь. Она меняется после содержательного ввода. Если пользователь дописал абзац, текущая версия уже не та, которую отправила первая попытка.</p>\n<p><code>requestKey</code> — идентификатор одной логической операции. Он отвечает на вопрос «что именно пользователь хочет завершить?». При разрешённом повторе request key сохраняется. Если создать новый ключ при каждом клике, сервер не сможет распознать повтор, если его контракт поддерживает идемпотентность.</p>\n<p><code>attemptKey</code> — идентификатор запуска. Он отвечает на вопрос «какой ответ сейчас ожидает интерфейс?». Первая попытка получает <code>attempt-01</code>, разрешённый повтор — <code>attempt-02</code>. Старый ответ с первым ключом не должен коммититься в состояние, которое ждёт второй.</p>\n<p><code>acknowledgement</code> — сообщение, которое API определило как подтверждение операции. Завершение локального обработчика, исчезновение спиннера и статус «запрос отправлен» подтверждением не являются. В payload нужны данные, по которым клиент проверит request key, attempt key и принятую версию.</p>\n<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>draft.version</td><td>При изменении текста</td><td>Новый текст от очистки старым ответом</td><td>Что текст принят сервером</td></tr><tr><td>requestKey</td><td>При создании новой логической операции</td><td>Связь повтора с исходным намерением</td><td>Что сервер умеет дедупликацию</td></tr><tr><td>attemptKey</td><td>При каждой разрешённой попытке</td><td>Поздний ответ другой попытки</td><td>Что запрос дошёл до сервера</td></tr><tr><td>acknowledgement</td><td>После ответа, прошедшего проверки</td><td>Переход в acknowledged</td><td>Что последующий ввод тоже сохранён</td></tr></tbody></table>\n<h2>Почему одного isPending недостаточно</h2>\n<p>Флаг <code>isPending</code> описывает только наличие ожидания. Он не говорит, какая версия текста отправлена и какой ответ ещё допустим. После timeout флаг обычно сбрасывают. Если запрос всё ещё выполняется, его поздний ответ получает возможность изменить уже новое состояние.</p>\n<p>Кнопка disabled тоже не является защитой. Событие могло попасть в очередь до блокировки. Другой обработчик может вызвать отправку напрямую. Восстановление страницы может загрузить старое pending-состояние. Правило нужно разместить на переходе состояния, а не только в визуальном элементе.</p>\n<p>Удобная минимальная машина имеет состояния <code>idle</code>, <code>awaiting-ack</code>, <code>unknown-outcome</code>, <code>acknowledged</code> и <code>recovery-required</code>. В <code>awaiting-ack</code> второй запуск блокируется. В <code>unknown-outcome</code> пользователь видит, что результат не установлен. Переход в <code>acknowledged</code> разрешает только проверенный acknowledgement. Переход в <code>recovery-required</code> сохраняет черновик и предлагает сверить результат, если повтор небезопасен.</p>\n<h2>Учебный пример с поздним ответом</h2>\n<p>Ниже не сетевой клиент и не production-код. Это компактная модель переходов. Она показывает только условие, при котором ответ может изменить локальное состояние.</p>\n<pre><code>const state = {\n  phase: 'awaiting-ack',\n  draftVersion: 2,\n  requestKey: 'request-17',\n  attemptKey: 'attempt-02',\n  submittedVersion: 1,\n};\n\nfunction acceptAck(current, ack) {\n  if (ack.requestKey !== current.requestKey) {\n    return { ...current, phase: 'stale-ack' };\n  }\n  if (ack.attemptKey !== current.attemptKey) {\n    return { ...current, phase: 'stale-ack' };\n  }\n  if (ack.acceptedVersion !== current.submittedVersion) {\n    return { ...current, phase: 'invalid-ack' };\n  }\n\n  return {\n    ...current,\n    phase: current.draftVersion === ack.acceptedVersion\n      ? 'acknowledged'\n      : 'acknowledged-newer-draft-retained',\n  };\n}\n\nconst lateAck = {\n  requestKey: 'request-17',\n  attemptKey: 'attempt-01',\n  acceptedVersion: 1,\n};\n\nconst next = acceptAck(state, lateAck);\n// next.phase === 'stale-ack'; draft version 2 не меняется</code></pre>\n<p>В примере первый ответ пришёл после второго запуска. Его request key совпадает, но attempt key устарел. Функция не очищает черновик и не показывает успех. Если позже придёт acknowledgement для <code>attempt-02</code>, он подтвердит только версию 1. Версия 2 останется черновиком. Это важная граница: подтверждение старой отправки не подтверждает последующий ввод.</p>\n<p>В реальном приложении состояние может лежать в reducer, store или другом слое. Названия не важны. Важно, чтобы каждый commit проверял владельца ответа и accepted version в одном месте. Не полагайтесь на порядок прихода событий.</p>\n<figure><img src=\"/assets/editorial/2022/poor-network-retry-contract-2022.svg\" alt=\"Схема разделения версии черновика, request key и attempt key при неизвестном исходе и повторной попытке\" loading=\"lazy\" /><figcaption>Иллюстрация показывает учебный контракт: новый текст сохраняет свою версию, повтор использует тот же request key и новый attempt key, а устаревший ответ не меняет текущий черновик.</figcaption></figure>\n<h2>Неизвестный исход и повтор</h2>\n<p>После transport error интерфейс знает только, что не получил ожидаемый ответ. Он не знает, отменил ли сервер операцию. Поэтому безопасный экран не подменяет неизвестный исход ошибкой без оговорки. Он оставляет черновик, показывает состояние проверки и выбирает действие по цене повтора.</p>\n<p>Для обычного текста продукт может разрешить один повтор. Он использует прежний request key и новый attempt key. Сервер должен понимать этот контракт, если повтор должен быть идемпотентным. Для финансового или иного необратимого действия повтор может быть запрещён. Тогда интерфейс переводит пользователя в recovery-required и даёт проверить результат через отдельный статусный путь.</p>\n<p>Бесконечный retry опасен. Он создаёт нагрузку, дублирует внешние эффекты и скрывает неизвестный результат за серией одинаковых попыток. Лимит, задержка, ручное подтверждение и способ сверки должны быть частью предметного контракта, а не случайным числом в обработчике.</p>\n<h2>Симптом → причина → проверка → действие</h2>\n<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>Новый текст исчез после старого ответа</td><td>Ответ не связан с attempt key или version</td><td>Сравнить ключи и accepted version перед очисткой draft</td><td>Отклонять stale ack и хранить новый draft отдельно</td></tr><tr><td>Два клика создали две операции</td><td>Retry создаёт новый request key</td><td>Сопоставить ключи в запросах и на стороне API</td><td>Разделить logical request и attempt; согласовать дедупликацию</td></tr><tr><td>UI показывает успех сразу после клика</td><td>Завершение handler-а принято за acknowledgement</td><td>Найти место, где phase меняется на success</td><td>Разрешать success только после проверки payload</td></tr><tr><td>После timeout пользователь повторяет необратимое действие</td><td>Нет состояния unknown-outcome и recovery-пути</td><td>Смоделировать потерю ответа после отправки</td><td>Показать неизвестный исход и дать сверить результат</td></tr><tr><td>Старый ответ закрывает форму</td><td>Обработчик смотрит только на форму, а не на попытку</td><td>Записать draft version, request key и attempt key каждого события</td><td>Проверять владельца ответа до каждого перехода</td></tr></tbody></table>\n<h2>Порядок действий</h2>\n<ol><li><strong>Зафиксируйте симптом.</strong> Запишите видимый текст, действие пользователя и цену ошибки. Не называйте проблему «offline», пока не отделили ошибку транспорта от неизвестного результата.</li><li><strong>Назовите версии.</strong> Выведите безопасные surrogate-значения для draft version, request key и attempt key. Не записывайте bearer-токены и чувствительный текст.</li><li><strong>Разделите переходы.</strong> Найдите места, где код создаёт попытку, очищает draft, показывает success и разрешает retry. Для каждого перехода укажите владельца.</li><li><strong>Проверьте отрицательный путь.</strong> Запустите сценарий: первая попытка без acknowledgement, новый ввод, повтор с новым attempt key, поздний ответ первой попытки. Ожидайте stale-результат без изменения нового draft.</li><li><strong>Проверьте положительный путь.</strong> Передайте acknowledgement с текущими request key, attempt key и accepted version. Убедитесь, что только он переводит состояние в acknowledged.</li><li><strong>Выберите политику повтора.</strong> Для каждой операции укажите лимит, сохранение request key, новый attempt key и действие при unknown-outcome. Для необратимого эффекта добавьте отдельную сверку.</li><li><strong>Согласуйте API.</strong> Определите, как сервер распознаёт повтор, что возвращает acknowledgement и как клиент получает статус операции после потерянного ответа.</li><li><strong>Проверьте реальную среду.</strong> Проведите отдельный browser/network-сценарий с указанными версиями браузера, приложения, API и способом потери ответа. Учебный код не заменяет этот результат.</li><li><strong>Оставьте наблюдение.</strong> Измеряйте долю unknown-outcome, stale acknowledgement, duplicate attempt и recovery-required. Значения ключей не должны раскрывать секреты.</li></ol>\n<h2>Service Worker не отменяет контракт</h2>\n<p>Фоновый worker может помочь с очередью или доставкой, но он не превращает неизвестный исход в подтверждённый. У Service Workers есть событийный жизненный цикл. User agent может остановить worker, когда нет события или когда выполнение нарушает ограничения. Поэтому нельзя обещать пользователю «фоновая часть точно завершит сохранение», если приложение не хранит очередь, не описывает acknowledgement и не умеет восстановить состояние.</p>\n<p>Если worker участвует в повторе, добавьте к контракту владельца очереди, срок хранения, версию черновика, правило дедупликации и сообщение для открытой страницы. Проверяйте обновление worker, перезагрузку и несколько вкладок отдельно. Worker в этой модели не запускается; модель не содержит реального сетевого прогона.</p>\n<h2>Ограничения и критерий готовности</h2>\n<p>Модель не решает конфликт двух вкладок, авторизацию, обновление токена, распределённое хранилище, шифрование локального текста, CRDT и серверную транзакцию. Она не определяет, какой HTTP-метод или заголовок должен использовать конкретный API. Идемпотентность метода не гарантирует идемпотентность вашей предметной операции. Это надо доказать контрактом сервиса.</p>\n<p>Учебный код ограничен памятью процесса. Он не создаёт HTTP-запрос, не имитирует задержку, не проверяет браузер и не заявляет production-результат. Названия <code>requestKey</code>, <code>attemptKey</code> и фаз — проектные значения. Их можно заменить, но нельзя убрать саму проверку связи ответа с операцией и версией.</p>\n<p>Критерий готовности закрыт, если команда может показать пять вещей: после потерянного ответа черновик остаётся доступным; повтор не создаёт новую логическую операцию без явного решения; поздний ответ старой попытки не меняет новую версию; acknowledgement старой версии не очищает новый текст; для необратимого эффекта существует отдельная проверка результата. Эти утверждения должны подтверждаться тестом или документированным сценарием с условиями. Один зелёный экран и исчезнувшая кнопка ожидания не являются доказательством.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href=\"https://fetch.spec.whatwg.org/\" target=\"_blank\" rel=\"noopener noreferrer\">WHATWG Fetch Standard</a> — официальная спецификация запросов, ответов и процесса fetching; она описывает транспортный слой, а не смысл сохранения черновика.</li><li><a href=\"https://www.rfc-editor.org/rfc/rfc9110.html\" target=\"_blank\" rel=\"noopener noreferrer\">RFC 9110: HTTP Semantics</a> — официальный стандарт HTTP о намерении методов, запросах и ответах; его свойства нельзя автоматически переносить на прикладную операцию.</li><li><a href=\"https://www.w3.org/TR/service-workers/\" target=\"_blank\" rel=\"noopener noreferrer\">W3C Service Workers</a> — официальная спецификация событийного worker и его жизненного цикла; она не подтверждает выполнение конкретной очереди в production.</li></ul>"}