Stripe помнит ваш запрос, когда ответ исчезает
Тайм-аут может оставить оформление заказа неопределенным после завершения операции сервером.
Тайм-аут может оставить оформление заказа неопределенным после завершения операции сервером. Этот объяснитель Under the Hood использует задокументированный контракт идемпотентности Stripe API v1, чтобы показать стабильные ключи операций, повторное воспроизведение сохраненного ответа, ограничения параметров и параллелизма, горизонт хранения и согласование результатов.
Читать письменное издание (на английском) ↗
Что освещается в этом видео
- Идемпотентность касается предполагаемого эффекта от повторения операции. Stripe API v1 добавляет задокументированный контракт повторного воспроизведения сохраненного ответа.
- Повторная попытка того же логического действия использует тот же ключ и параметры. Сохраняйте ключ операции при отдельных вызовах SDK или перезапусках приложения; действительно новое действие нуждается в собственном ключе.
- После начала выполнения конечной точки Stripe API v1 сохраняет статус и тело первого запроса, включая ошибки 500, и возвращает этот сохраненный ответ при повторных попытках.
- Измененные параметры с тем же ключом приводят к несоответствию. Ошибки валидации и конфликты параллельного выполнения не сохраняют идемпотентный результат для этой попытки и могут быть повторены.
- Stripe хранит ключи API v1 не менее 24 часов и может удалить их после этого. Ограничьте неразрешенные повторные попытки сети первыми 24 часами, затем остановитесь и согласуйте, прежде чем повторять операцию.
- Кэшированная ошибка 500 может продолжать воспроизводиться после восстановления соединения. Исходная операция могла иметь побочные эффекты; используйте соответствующий объект, запрос на панели управления и веб-хуки для установления ее результата.
- API v2 использует другую семантику повторного воспроизведения. Ключ не устанавливает универсальную доставку ровно один раз для электронной почты, инвентаризации и каждой операции локальной базы данных.
Переведенная стенограмма
Переведено с оригинального английского повествования. Доступные аудио и субтитры контролируются YouTube.
Отменил ли тайм-аут ваш платеж?
0:00 Вы думаете, что тайм-аут означает, что ваш платеж не удался. Сервер может завершить работу, пока ответ исчезает, оставляя ваше оформление заказа уверенно отображать абсолютно ничего. Почему повторная попытка может списать деньги снова? Как Stripe запоминает попытку? Когда следует прекратить повторные попытки? И имейте в виду одну неприятную деталь. Запомненная ошибка может пережить проблему с сетью.
0:17 Мы вернемся к этому. Это The Daily Diff, под капотом.
Что идентифицирует ключ идемпотентности?
0:21 Идемпотентность означает, что повторение операции имеет тот же предполагаемый эффект, что и выполнение ее один раз. Ключ идемпотентности обозначает одно логическое действие. Stripe API версии один распознает эту метку при повторных попытках и воспроизводит сохраненный ответ. Представьте себе покупку кофе. Stripe завершает ваш платежный запрос, и ответ теряется при возвращении домой. Клиент видит спиннер. Его банк может иметь более захватывающую интерпретацию. Незащищенный запрос на создание может повторить побочный эффект.
Как один и тот же ключ делает повторную попытку безопасной?
0:45 Прикрепите уникальный ключ перед первой попыткой и сохраните его для повторных попыток. Если ваше приложение перезапускается, сохраните этот ключ вместе с операцией в своих записях. Для Stripe API версии один, как только начинается выполнение конечной точки, статус и тело первого запроса сохраняются. Отправьте тот же ключ и параметры снова, и Stripe вернет сохраненный ответ. Кофе остается на месте, пока его чек снова отправляется.
Что именно сохраняет Stripe?
1:07 Вот фактическая формулировка Stripe. Повторные попытки с тем же ключом возвращают сохраненный ответ, включая пятисотые ошибки. Документация делает больше работы, чем ваш оптимистично названный помощник по повторным попыткам. Клиент снова нажимает. Ваше приложение решает, возобновляет ли это ожидающую покупку или начинает другую одну. Действительно новый кофе получает новый ключ. Новый ключ для каждой повторной попытки сети отменяет защиту.
1:27 Разные параметры с тем же ключом вызывают несоответствие.
Что происходит при изменении запроса?
1:30 Если параметры не проходят проверку, или другой запрос с этим ключом все еще выполняется, Stripe не сохраняет идемпотентный результат для этой попытки. Эти запросы могут быть повторены. Гонка запросов приводит к конфликту. Это правила версии один. Версия два ведет себя по-другому. Заголовок не может обещать доставку ровно один раз по всей вашей системе. Электронная почта, инвентаризация и ваша база данных нуждаются в обработке сбоев.
1:52 Ключ защищает операцию в рамках ее задокументированной области. Stripe хранит ключи версии один не менее двадцати четырех часов и может удалить
Как долго запомненный результат безопасен для повторной попытки?
1:59 их после этого. Удаленный ключ может выполнить новый запрос. Оставляйте неразрешенные повторные попытки в течение первого дня. После этого остановитесь и согласуйте исходный результат. Используйте экспоненциальную задержку и джиттер, чтобы дать серверу передышку. В противном случае повторные попытки образуют очередь за горящим кафе. Библиотеки Stripe обрабатывают повторные попытки, но проверьте настройки по умолчанию вашей библиотеки. Эта липкая ошибка - вот в чем подвох.
Почему запомненная ошибка может постоянно возвращаться?
2:20 Кэшированный ответ пятьсот продолжает воспроизводиться после восстановления соединения. Исходная операция могла произвести побочные эффекты. Разрешите ее результат с помощью объектов, панели управления и веб-хуков. Новый ключ может повторить действие. Если вы предпочитаете читать это, чем слышать, как я это говорю, diff приходит в ваш почтовый ящик каждое утро, бесплатно на the daily diff dot dev, ссылка ниже.
Отправил бы я кнопку повторной попытки с этим контрактом?
2:39 Вердикт, под капотом. SHIP IT. Я бы отправил стабильные ключи с ограниченными повторными попытками и согласованием, чтобы клиенты получали кофе, не финансируя ваше образование в области распределенных систем. И это весь diff на сегодня. Я Нико из Axrisi. Ответственно объединяйте.
Источники
- Idempotent requestsStripe Docs
- Designing robust and predictable APIs with idempotencyStripe Engineering — Brandur Leach
- Advanced error handlingStripe Docs
- HTTP Semantics — RFC 9110 §9.2.2 Idempotent MethodsIETF / RFC Editor



