Medusa, оформление заказа и списание денег, февраль — август 2026.

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

Medusa эту защиту сделала. Дальше — про то, как она сработала.

Приходит разработчик под ником sricharan505 (#14757). У него не оформляется корзина: сервер отвечает конфликтом.

throw new MedusaError(MedusaError.Types.CONFLICT, "Cart is already being completed by another request")

«Корзина уже оформляется другим запросом»

Он описывает то, что видит, тремя строками, и каждая из них важна:

The cart eventually gets completed after some time (likely after the locking duration). If I retry using the same cart ID, it succeeds after waiting.

Корзина в итоге оформляется через какое-то время — видимо, когда истекает блокировка. Если повторить с тем же id корзины, получается, но надо подождать.

И, отдельной строкой:

I have seen similar issues reported earlier, but they were closed without a resolution.

Я видел похожие сообщения раньше, но их закрывали без решения.

Задачу закрывают в тот же день со статусом not planned. В тот же день заведена и её близнец — #14758, с тем же названием.

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

Защита сработала: второго заказа нет. И покупателя тоже нет.

Через полгода приходит blockgroot и приносит вторую половину (#16292). Название задачи — это уже почти весь разбор:

Retrying a payment capture after a provider-side failure sends a different idempotency key

Повтор списания после сбоя на стороне провайдера отправляет другой ключ идемпотентности

Воспроизводится это не в интерфейсе, а тестом: заставить провайдера упасть один раз (будто по таймауту) и ответить успехом на второй.

Each attempt mints a fresh Capture row and therefore a fresh idempotency key, regardless of whether the previous attempt failed ambiguously.

Каждая попытка заводит новую запись списания и, значит, новый ключ идемпотентности — независимо от того, чем закончилась предыдущая.

Слово ambiguously здесь несущее. Провайдер не ответил — это не «не списал». Это «неизвестно». Ровно для этого случая ключ идемпотентности и придуман: повтори с тем же ключом, и провайдер узнает свою же операцию вместо того, чтобы списать второй раз.

А ключ каждый раз новый.

Защита от двойной отправки есть, и она честно работает — в двух местах, и оба раза мимо цели.

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

Там, где повтор стоит денег — списание, провайдер не ответил, — она пропускает, потому что ключ на повторе другой.

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