Ответ потерялся: повтор без дублей и без лжи

Начнём с хорошей новости. Повтор пачки «Подхода» сам по себе безвреден, и это не случайность, а следствие двух решений главы 6. Первое: имя строке даёт телефон — A-1, «устройство плюс счётчик», а не сервер. Второе: операция несёт «поле равно значению» — { weightKg: 82.5 }, а не «прибавь два с половиной». Наложить такую операцию один раз и наложить её трижды — это одно и то же.

Проверим на рубильнике «ответ потерялся» из статьи про сервер-партнёра, только грубее: телефон шлёт одну и ту же пачку из двух операций три раза подряд, ни разу не услышав ответа. Прогноз: сколько у сервера окажется строк, сколько записей в журнале — и что после этого увидит веб-версия, пришедшая с нулевого курсора?

type Fields = Record<string, string | number>;
type Row = Fields & { id: string };
type Op = { opId: string; rowId: string; fields: Fields; at: number };
type Verdict = { opId: string; status: "applied" | "duplicate" | "rejected"; reason?: string };
interface Server {
  rows: Map<string, Row>;
  journal: (Op & { seq: number })[];
  net: { offline: boolean; loseResponse: boolean };
  push(batch: Op[]): { verdicts: Verdict[] };
  pull(cursor: number, limit: number): { changes: (Op & { seq: number })[]; cursor: number; hasMore: boolean };
}
declare function createServer(): Server;

const server = createServer();
// та же пачка уходит трижды: ответ не доехал ни разу, телефон пробует снова
const outbox: Op[] = [
  { opId: "A:1", rowId: "A-1", fields: { exercise: "жим", weightKg: 80, reps: 5 }, at: 1 },
  { opId: "A:2", rowId: "A-1", fields: { weightKg: 82.5 }, at: 2 },
];
for (let attempt = 1; attempt <= 3; attempt += 1) {
  const verdicts = server.push(outbox).verdicts;
  console.log(
    "попытка " + attempt + ":", verdicts.map((v) => v.status).join(", "),
    "| строк", server.rows.size, "| записей журнала", server.journal.length,
  );
}
console.log("строка:", JSON.stringify([...server.rows.values()]));

// веб-версия открывается впервые и забирает всё, что накопилось у сервера
const page = server.pull(0, 100);
console.log("веб-версия увидит операций:", page.changes.length, "| курсор", page.cursor);

Строка одна, и она правильная: вес 82.5, упражнение на месте. Три повтора не создали ни одного дубля в дневнике — ровно то, на что мы рассчитывали. А вот журнал сервера вырос втрое: шесть записей на одну-единственную строку, и каждая получила свой номер.

Вот здесь и прячется цена. Номер — это курсор: веб-версия, открывшаяся впервые, забирает шесть операций вместо двух и складывает из них ту же строку. Пока устройств два, это лишний трафик. Когда телефон месяц пролежал без сети и повторял каждую пачку по пять раз, это уже разница между «дневник переехал за секунду» и «переносим 12 тысяч операций». Фильтр эха из прошлой статьи здесь не помогает: он спасает от собственных операций своё же устройство, а чужому телефону эти шесть записей приедут как шесть настоящих изменений.

Идемпотентна здесь операция, а не запрос. «Повторить запрос безопасно» — утверждение не про HTTP-метод и не про библиотеку повторов, а про то, что именно лежит в теле: «поле равно значению» переживает повтор, «прибавь один» — нет.

type Fields = Record<string, string | number>;
type Row = Fields & { id: string };
type Op = { opId: string; rowId: string; fields: Fields; at: number };
type Verdict = { opId: string; status: "applied" | "duplicate" | "rejected"; reason?: string };
interface Server {
  rows: Map<string, Row>;
  journal: (Op & { seq: number })[];
  net: { offline: boolean; loseResponse: boolean };
  push(batch: Op[]): { verdicts: Verdict[] };
  pull(cursor: number, limit: number): { changes: (Op & { seq: number })[]; cursor: number; hasMore: boolean };
}
declare function createServer(): Server;

const server = createServer();
const insert: Op = { opId: "A:1", rowId: "A-1", fields: { exercise: "жим", weightKg: 80, reps: 5 }, at: 1 };
const editWeight: Op = { opId: "A:2", rowId: "A-1", fields: { weightKg: 82.5 }, at: 2 };

server.push([insert]);
server.push([editWeight]);
console.log("после двух операций:", server.rows.get("A-1")?.weightKg);

// первая пачка ушла без ответа, и телефон шлёт её повторно — уже после правки
server.push([insert]);
console.log("после повтора первой:", server.rows.get("A-1")?.weightKg);

Безвредность повтора — свойство не синхронизации вообще, а конкретной формы операции. Стоит форме измениться, и повтор перестаёт быть повтором. Три случая ниже — самые частые, и первый из них объясняет задним числом решение главы 6, которое тогда выглядело причудой.

Случай первый: имя строке выдаёт сервер. Так устроено большинство привычных API — POST /sets возвращает созданную запись с её новым id. Прогноз: что будет у такого сервера после повтора одной и той же записи?

type Fields = Record<string, string | number>;

// сервер, который придумывает имя строке сам: id — его порядковый номер
function createNumberingServer() {
  const rows = new Map<string, Fields>();
  let seq = 0;
  return {
    rows,
    addSet(fields: Fields) {
      seq += 1;
      rows.set("s" + seq, fields);
      return "s" + seq;
    },
  };
}

const server = createNumberingServer();
const set: Fields = { exercise: "жим", weightKg: 80, reps: 5 };
// запрос ушёл, ответ не доехал — телефон отправляет тот же подход ещё раз
server.addSet(set);
server.addSet(set);
console.log("строк на сервере:", server.rows.size, "|", JSON.stringify([...server.rows.keys()]));
console.log("оба подхода:", JSON.stringify([...server.rows.values()]));

Два подхода вместо одного, и различить их нельзя ничем: поля совпадают до последней цифры. Человек увидит в ленте два одинаковых жима подряд и решит, что это он сам нажал дважды. Хуже того, удалить лишний придётся вручную — программа не знает, какой из них настоящий. Именно ради этого случая идентификатор в главе 6 рождался на телефоне: имя, придуманное до отправки, переживает любое число повторов.

Случаи второй и третий живут уже внутри операции. «Прибавь один подход к счётчику недели» — привычная форма записи для счётчиков. А правка «по версии» — привычная защита от параллельных изменений: операция несёт номер версии строки, и сервер применяет её, только если версия совпала. Прогноз: что даст повтор каждой из них?

// счётчик недели: операция говорит «прибавь», а не «стало столько»
const weekly = { sets: 0 };
function addSet(by: number) {
  weekly.sets += by;
}
addSet(1);
addSet(1);
console.log("подходов за неделю:", weekly.sets);

// правка по версии строки: применяем, только если версия совпала
const row = { id: "A-1", weightKg: 80, version: 1 };
function editIfVersion(expected: number, weightKg: number) {
  if (row.version !== expected) return "конфликт: версия " + row.version + ", ждали " + expected;
  row.weightKg = weightKg;
  row.version += 1;
  return "применено";
}
console.log("правка веса:", editIfVersion(1, 82.5));
console.log("тот же повтор:", editIfVersion(1, 82.5));
console.log("строка:", JSON.stringify(row));

Счётчик насчитал два подхода вместо одного — обычная арифметика, никакой ошибки в коде нет. А правка по версии на повторе ответила конфликт: версия строки уже 2, а операция всё ещё ждёт 1. Это ложный конфликт, и он неприятнее дубля. Дубль хотя бы виден; ложный конфликт заставляет клиента разрешать расхождение, которого не существует — правку-то сделал он сам, и она уже применена. Дальше начинается ручное «перечитать строку и попробовать снова», и в оффлайне это превращается в петлю.

Соблазн прочитать таблицу так: «будем писать только операции из первой строки, и память не понадобится». Не выйдет. Счётчики, номера от сервера и проверка версии появляются в любом приложении, которое выросло: уже удаление с восстановлением или связь «подход принадлежит тренировке» выводят за пределы «поле равно значению».

Общее лекарство одно: сервер должен узнавать повтор. Для этого нужен ключ, который у операции уже есть — opId из главы 6. Он придуман телефоном до отправки, уникален в пределах устройства и, главное, не меняется при повторе: повторяется ровно та же операция, а не «такая же». В платёжных API этот приём называют ключом идемпотентности; там его придумывает клиент и присылает заголовком, у нас он просто лежит внутри операции.

Память — это Map из opId в уже выданный ответ. Сравним сервер с памятью и сервер без неё на одной и той же повторённой операции. Прогноз: сколько у каждого окажется строк, сколько записей в журнале и что получит телефон в ответ на повтор?

type Fields = Record<string, string | number>;
type Row = Fields & { id: string };
type Op = { opId: string; rowId: string; fields: Fields; at: number };
type Verdict = { opId: string; status: "applied" | "duplicate" | "rejected"; reason?: string };
interface Server {
  rows: Map<string, Row>;
  journal: (Op & { seq: number })[];
  net: { offline: boolean; loseResponse: boolean };
  push(batch: Op[]): { verdicts: Verdict[] };
  pull(cursor: number, limit: number): { changes: (Op & { seq: number })[]; cursor: number; hasMore: boolean };
}
declare function createServer(): Server;

// память сервера: opId → ответ, который по этой операции уже выдан
const answered = new Map<string, Verdict>();
function pushOnce(server: Server, batch: Op[]): Verdict[] {
  return batch.map((op) => {
    if (answered.has(op.opId)) return { opId: op.opId, status: "duplicate" };
    const verdict = server.push([op]).verdicts[0];
    answered.set(op.opId, verdict);
    return verdict;
  });
}

const outbox: Op[] = [
  { opId: "A:1", rowId: "A-1", fields: { exercise: "жим", weightKg: 80, reps: 5 }, at: 1 },
];

const forgetful = createServer();
forgetful.push(outbox);
forgetful.push(outbox);
console.log("не помнит: строк", forgetful.rows.size, "| записей журнала", forgetful.journal.length);

const server = createServer();
pushOnce(server, outbox);
const again = pushOnce(server, outbox);
console.log("помнит: строк", server.rows.size, "| записей журнала", server.journal.length);
console.log("что вернул повтор:", again.map((v) => v.opId + " " + v.status).join(", "));

У обоих по одной строке — этого мы и ждали после первого раздела. Разница в журнале: без памяти в нём две записи, с памятью одна. Лишний номер не выдан, курсор другим устройствам не сдвинут, чужой телефон не получит фантом. А телефон, приславший повтор, услышал duplicate — третий вердикт из контракта статьи про сервер-партнёра, который до сих пор не выносился ни разу. По таблице вердиктов телефон уносит такую операцию из очереди как принятую: она действительно принята, просто в прошлый раз.

Присмотритесь к памяти внимательнее: ответ в неё кладётся, а повтору отдаётся не он — повтору отдаётся duplicate, всегда и без разбора. Пока каждая операция проходит, разницы нет никакой. Всё «пока» этой фразы разбирается в следующем разделе.

Память нужна серверу, а не телефону. Телефон и так знает, что он повторяет: операция лежит в его очереди с неотвеченным вердиктом. Знать, что она уже применена, может только та сторона, которая её применила.

Теперь самое тонкое место статьи, и стоит оно ровно в одной строке кода: когда сервер записывает opId в память. Напрашивается записать сразу, как только операция пришла, — «видел, обработал, отметил». Разница между «сразу» и «после вердикта» не видна ни на одном успешном сценарии. Она видна только там, где сходятся две вещи: операцию отвергли и ответ об этом потерялся.

В очереди телефона одна операция — подход с опечаткой, 800 повторов, тот самый, который сервер обязан отвергнуть. Первая отправка доходит, ответ — нет. Телефон шлёт её снова. Прогноз: что ответит на повтор сервер, помнящий факт, и что — сервер, помнящий вердикт? И сколько у каждого строк?

type Fields = Record<string, string | number>;
type Row = Fields & { id: string };
type Op = { opId: string; rowId: string; fields: Fields; at: number };
type Verdict = { opId: string; status: "applied" | "duplicate" | "rejected"; reason?: string };
interface Server {
  rows: Map<string, Row>;
  journal: (Op & { seq: number })[];
  net: { offline: boolean; loseResponse: boolean };
  push(batch: Op[]): { verdicts: Verdict[] };
  pull(cursor: number, limit: number): { changes: (Op & { seq: number })[]; cursor: number; hasMore: boolean };
}
declare function createServer(): Server;

// память о ФАКТЕ: имя операции записывается до того, как по ней вынесен ответ
const seen = new Set<string>();
function pushFact(server: Server, batch: Op[]): Verdict[] {
  return batch.map((op) => {
    if (seen.has(op.opId)) return { opId: op.opId, status: "duplicate" };
    seen.add(op.opId);
    return server.push([op]).verdicts[0];
  });
}

// память о ВЕРДИКТЕ: запоминается сам ответ, а не отметка «был»
const answered = new Map<string, Verdict>();
function pushVerdict(server: Server, batch: Op[]): Verdict[] {
  return batch.map((op) => {
    const known = answered.get(op.opId);
    if (known) return known.status === "applied" ? { opId: op.opId, status: "duplicate" } : known;
    const verdict = server.push([op]).verdicts[0];
    answered.set(op.opId, verdict);
    return verdict;
  });
}

// в очереди телефона подход с опечаткой: 800 повторов подряд человек не делает
const outbox: Op[] = [
  { opId: "A:1", rowId: "A-1", fields: { exercise: "присед", weightKg: 100, reps: 800 }, at: 1 },
];
const say = (server: Server, verdicts: Verdict[], label: string) => {
  console.log(label, verdicts.map((v) => (v.opId + " " + v.status + " " + (v.reason ?? "")).trim()).join(", "));
  console.log("а строк на сервере:", server.rows.size);
};

const byFact = createServer();
pushFact(byFact, outbox); // ответ не доехал: вердиктов телефон не услышал
say(byFact, pushFact(byFact, outbox), "память о факте →");

const byVerdict = createServer();
pushVerdict(byVerdict, outbox); // ответ не доехал точно так же
say(byVerdict, pushVerdict(byVerdict, outbox), "память о вердикте →");

Строк нет ни у того, ни у другого — оба отвергли операцию правильно. Но ответы разные, и вот что за ними стоит. Сервер, помнящий факт, сказал duplicate: «эту операцию я уже видел». Телефон по таблице вердиктов уносит её из очереди как принятую — и подход с 800 повторами навсегда остаётся на экране телефона, хотя у сервера его нет и никогда не будет. Отправлять больше нечего, спрашивать не о чем, и никакая следующая синхронизация этого уже не исправит: расхождение стало вечным.

Сервер, помнящий вердикт, ответил тем же отказом и той же причиной — повторов больше сотни. Потерянный ответ перестал быть потерянным: телефон получил его со второй попытки, слово в слово. Отсюда правило: в память кладётся ответ, а не отметка «был», и кладётся он после того, как вынесен, — вместе с применением, одним шагом. Повтор не обрабатывается заново, он перечитывает ответ.

Полезная формулировка: duplicate — это не «я это применил», а «у меня уже есть ответ по этой операции, и он был applied». Тогда сразу видно, почему отказ нельзя пересказывать словом duplicate: у него другой ответ, и телефону нужен именно он.

Память переезжает внутрь сервера-миниатюры: одна строка на саму память и три внутри push. Дальше он такой в подложке всех следующих статей:

// сервер-партнёр: память вердиктов внутри push
const answered = new Map<string, Verdict>();

function push(batch: Op[]) {
  if (net.offline) throw new Error("сети нет");
  const verdicts = batch.map((op) => {
    const known = answered.get(op.opId);
    // повтор получает тот же ответ: принято — «уже было», отказ — тот же отказ
    if (known) return known.status === "applied" ? { opId: op.opId, status: "duplicate" } : known;
    const verdict = take(op);
    answered.set(op.opId, verdict);
    return verdict;
  });
  // рубильник стоит ПОСЛЕ записи в память: сервер всё сделал, потерялся ответ
  if (net.loseResponse) throw new Error("ответ потерялся");
  return { verdicts };
}

Обратите внимание на порядок в последних строках: рубильник «ответ потерялся» срабатывает уже после того, как вердикты вынесены и записаны. Иначе миниатюра изображала бы не потерю ответа, а неслучившийся запрос — и вся статья проверяла бы не то.

Соберём всё вместе с настоящим циклом синхронизации из прошлой статьи. Телефон записывает два подхода: нормальный жим и присед с опечаткой. Первая синхронизация теряет ответ, вторая проходит. Прогноз: что останется на экране после первой попытки и что — после второй?

type Fields = Record<string, string | number>;
type Row = Fields & { id: string };
type Op = { opId: string; rowId: string; fields: Fields; at: number };
type Verdict = { opId: string; status: "applied" | "duplicate" | "rejected"; reason?: string };
interface Server {
  rows: Map<string, Row>;
  journal: (Op & { seq: number })[];
  net: { offline: boolean; loseResponse: boolean };
  push(batch: Op[]): { verdicts: Verdict[] };
  pull(cursor: number, limit: number): { changes: (Op & { seq: number })[]; cursor: number; hasMore: boolean };
}
declare function createServer(): Server;
interface Client {
  store: { list(): Row[] };
  journal: { newId(): string; change(rowId: string, fields: Fields): void };
  queue(): Op[];
  sync(): Verdict[];
}
declare function createClient(device: string, server: Server): Client;

const server = createServer();
const phone = createClient("A", server);
phone.journal.change(phone.journal.newId(), { exercise: "жим", weightKg: 80, reps: 5 });
phone.journal.change(phone.journal.newId(), { exercise: "присед", weightKg: 100, reps: 800 });

// сервер всё разберёт, а ответ до телефона не доедет
server.net.loseResponse = true;
try {
  phone.sync();
} catch (error) {
  console.log("первая попытка:", (error as Error).message);
}
console.log("на экране:", JSON.stringify(phone.store.list()), "| ждут отправки", phone.queue().length);
console.log("у сервера строк:", server.rows.size);

// связь вернулась, телефон шлёт ту же пачку
server.net.loseResponse = false;
const rejected = phone.sync();
console.log("повтор принёс:", rejected.map((v) => v.opId + " " + v.status + " · " + v.reason).join(", "));
console.log("на экране:", JSON.stringify(phone.store.list()), "| ждут отправки", phone.queue().length);

После первой попытки телефон и сервер разошлись ровно так, как описано в статье про сервер-партнёра: у сервера строка жима уже есть, телефон об этом не знает и держит в очереди обе операции. Обе строки на экране — и хорошая, и та, которую сервер отверг.

Повтор всё расставил по местам. Жим вернулся с duplicate и молча ушёл из очереди. Присед вернулся с тем же rejected и причиной — и здесь сработало правило отказа из прошлой статьи: операция выбрасывается, строка пересобирается из оставшихся, а так как не осталось ни одной, строка уходит с экрана. Очередь пуста, дневник сошёлся с сервером, причину можно показать человеку словами.

В части IV похожее поведение давал useOptimistic («useOptimistic: показать результат заранее») — заново это не объясняется, и здесь оно не нужно: отменяется не показ, а операция. Запись не была предварительной, она лежит на диске с момента нажатия; лента подписана на хранилище через useSyncExternalStore («Свой хук: логика без разметки»), и экран перерисуется сам, когда журнал изменится.

Проверка, которую стоит завести привычкой: выключить ответ сервера в середине сценария и прогнать его дважды. Всё, что после этого разъезжается, разъедется и в метро. Протокол, в котором про повтор ничего не сказано, просто не проверялся.

В части VI на место миниатюры встанет настоящий сервер, и память вердиктов станет таблицей: op_id — первичный ключ (там он станет парой с пользователем), рядом вердикт. База тогда сама не даст записать операцию дважды. Отсюда рождается соблазнительная мысль: ничего не проверять заранее, а просто ловить ошибку уникальности и считать её за «уже было». Посмотрим, что из этого выходит на настоящем Postgres, если пачка применяется одной транзакцией.

$ cat пачка.sql
create temp table sync_ops (op_id text primary key, row_id text, fields jsonb);
insert into sync_ops values ('A:1', 'A-1', '{"reps":5}');

-- пачка, в которой первая операция — повтор уже принятой
begin;
insert into sync_ops values ('A:1', 'A-1', '{"reps":5}');
insert into sync_ops values ('A:2', 'A-2', '{"reps":8}');
commit;
select string_agg(op_id, ',' order by op_id) as "в журнале" from sync_ops;

-- та же пачка, но с ключом идемпотентности
begin;
insert into sync_ops values ('A:1', 'A-1', '{"reps":5}') on conflict (op_id) do nothing;
insert into sync_ops values ('A:2', 'A-2', '{"reps":8}') on conflict (op_id) do nothing;
commit;
select string_agg(op_id, ',' order by op_id) as "в журнале" from sync_ops;

$ psql -d postgres -f пачка.sql

Дубль не просто вернул ошибку — он оборвал транзакцию целиком: «current transaction is aborted, commands ignored until end of transaction block». Вторая операция, с которой всё было в порядке, до базы не дошла вовсе, и после отката в журнале осталась одна A:1. Это ядовитая операция из первой статьи главы, только роль яда играет обычный повтор — и на телефоне с потерянным ответом он случается каждый день.

Вторая пачка — та же самая, но каждая вставка помечена on conflict (op_id) do nothing. Повтор тихо вставил ноль строк, соседняя операция прошла, и в журнале стало A:1,A:2. Ноль возвращённых строк — это и есть сигнал «операция уже была»: по нему сервер читает сохранённый вердикт и отдаёт его повтору вместо нового разбора.

// приём пачки в части VI: та же память вердиктов, только таблицей
const [saved] = await tx
  .insert(syncOps)
  .values({ opId: op.opId, rowId: op.rowId, fields: op.fields, verdict })
  .onConflictDoNothing()
  .returning({ verdict: syncOps.verdict });

// строк не вернулось — операция уже была: отдаём сохранённый ответ, а не новый
return saved ? saved.verdict : await readVerdict(tx, op.opId);

Приём не выдуманный: в боевом коде автора вставка «создать или получить» сделана ровно так — частичный уникальный индекс плюс onConflictDoNothing() с returning(), а не проверка «есть ли уже» перед вставкой. Разница именно в том, что проверка и вставка разъезжаются во времени, а индекс — нет.

Один вопрос остаётся открытым честно: память вердиктов растёт вечно, а бесконечных таблиц не бывает. Сколько хранить opId, что отвечать на повтор, пришедший позже срока, и как связать это с горизонтом курсора — это уже работа сервера, и разбирается она в части VI.

Уникальный индекс по op_id стоит завести даже там, где память вердиктов уже написана в коде. Код обходят миграции, ручные правки и второй экземпляр сервера, поднятый рядом; индекс не обходит никто.