+− THE DAILY DIFFdev & AI news
SHIP IT

Stripe lembra a túa solicitude cando a resposta desaparece

Un tempo de espera pode deixar un pago incerto despois de que o servidor completase a operación.

Un tempo de espera pode deixar un pago incerto despois de que o servidor completase a operación. Esta explicación de Under the Hood utiliza o contrato de idempotencia documentado da API v1 de Stripe para mostrar claves de operación estables, a repetición da resposta gardada, os límites de parámetros e concorrencia, o horizonte de retención e a conciliación de resultados.

Ler a edición escrita (inglés) ↗

Que abrangue este vídeo

  • A idempotencia refírese ao efecto previsto de repetir unha operación. A API v1 de Stripe engade un contrato de repetición de resposta gardada documentado.
  • Un reintento da mesma acción lóxica utiliza a mesma clave e os mesmos parámetros. Persiste a clave de operación a través de chamadas SDK separadas ou reinicios da aplicación; unha acción realmente nova necesita a súa propia clave.
  • Despois de que comece a execución do punto final, a API v1 de Stripe garda o estado e o corpo da primeira solicitude, incluídos os erros 500, e devolve esa resposta gardada nos reintentos.
  • Os parámetros cambiados coa mesma clave producen unha falta de coincidencia. Os fallos de validación e os conflitos de execución simultánea non gardan ningún resultado idempotente para ese intento e pódense volver tentar.
  • Stripe retén as claves da API v1 durante polo menos 24 horas e pode eliminalas despois. Limita os reintentos de rede sen resolver ás primeiras 24 horas, despois detente e concilia antes de repetir a operación.
  • Un 500 en caché pode seguir reproducíndose despois de que a conectividade se recupere. A operación orixinal pode ter efectos secundarios; utiliza o obxecto relevante, a solicitude do Dashboard e os webhooks para establecer o seu resultado.
  • A API v2 utiliza unha semántica de repetición diferente. Unha clave non establece unha entrega exactamente unha vez universal para o correo electrónico, o inventario e cada operación de base de datos local.

Transcrición traducida

Traducido da narración orixinal en inglés. O audio e os subtítulos dispoñibles son controlados por YouTube.

Cancelou un tempo de espera o teu pago?

0:00 Pensas que un tempo de espera significa que o teu pago fallou. O servidor pode rematar mentres a resposta desaparece, deixando o teu proceso de pago mostrando absolutamente nada con confianza. Por que un reintento pode volver cobrar? Como lembra Stripe un intento? Cando debes deixar de volver intentar? E ten en conta un detalle desagradable. Un erro lembrado pode sobrevivir ao problema de rede.

0:17 Xa volveremos a iso. Este é The Daily Diff, baixo o capó.

Que identifica unha clave de idempotencia?

0:21 Idempotencia significa que repetir unha operación ten o mesmo efecto previsto que facela unha vez. Unha clave de idempotencia etiqueta unha acción lóxica. A versión un da API de Stripe recoñece esa etiqueta nos reintentos e reproduce unha resposta gardada. Imaxina mercar un café. Stripe completa a túa solicitude de pago e a resposta pérdese ao regresar a casa. O cliente ve un spinner. O seu banco pode ter unha interpretación máis emocionante. Unha solicitude de creación non protexida pode repetir o efecto secundario.

Como fai a mesma clave que un reintento sexa seguro?

0:45 Anexa unha clave única antes do primeiro intento e consérvaa para os reintentos. Se a túa aplicación se reinicia, preserva esa clave coa operación nos teus rexistros. Para a API de Stripe versión un, unha vez que comeza a execución do punto final, gardaranse o estado e o corpo da primeira solicitude. Envía a mesma clave e os mesmos parámetros de novo, e Stripe devolverá a resposta gardada. O café permanece no seu lugar mentres o seu recibo volve viaxar.

Que garda exactamente Stripe?

1:07 Aquí está a redacción real de Stripe. Os reintentos coa mesma clave devolven a resposta gardada, incluíndo erros cincocentos. A documentación fai máis traballo que o teu axudante de reintentos optimista. O cliente volve tocar. A túa aplicación decide se iso retoma a compra pendente ou inicia outra unha. Un café realmente novo obtén unha clave nova. Unha clave nova para cada reintento de rede anula a protección.

1:27 Diferentes parámetros coa mesma clave desencadean unha falta de coincidencia.

Que ocorre cando cambia a solicitude?

1:30 Se os parámetros non pasan a validación, ou outra solicitude con esa clave aínda está executándose, Stripe non garda ningún resultado idempotente para ese intento. Esas solicitudes pódense volver intentar. Unha solicitude en competición obtén un conflito. Estas son as regras da versión un. A versión dous compórtase de forma diferente. Unha cabeceira non pode prometer unha entrega exactamente unha vez en todo o teu sistema. O correo electrónico, o inventario e a túa base de datos necesitan cada un a xestión de fallos.

1:52 A clave protexe a operación dentro do seu ámbito documentado. Stripe retén as claves da versión un durante polo menos vinte e catro horas e pode eliminalas

Canto tempo é seguro volver tentar o resultado lembrado?

1:59 despois. Unha clave eliminada pode executar unha nova solicitude. Mantén os reintentos sen resolver dentro do primeiro día. Máis alá diso, detente e concilia o resultado orixinal. Utiliza un retroceso exponencial e tremores para dar espazo ao servidor. Se non, os reintentos forman unha cola fóra dunha cafetería en chamas. As bibliotecas de Stripe xestionan os reintentos, pero verifica os valores predeterminados da túa biblioteca. Ese erro persistente é o problema.

Por que un erro lembrado pode seguir volvendo?

2:20 Unha resposta cincocentos en caché segue reproducíndose despois de que a conectividade se recupere. A operación orixinal puido producir efectos secundarios. Resolve o seu resultado utilizando obxectos, o Dashboard e os webhooks. Unha nova clave pode repetir a acción. Se prefires ler isto en lugar de escoitarme dicilo, o diff chega á túa caixa de entrada todas as mañás, de balde en the daily diff dot dev, ligazón a continuación.

Enviaríame un botón de reintento con este contrato?

2:39 Veredicto, baixo o capó. Envíao. Eu enviaría claves estables con reintentos limitados e conciliación, para que os clientes poidan tomar café sen financiar a túa educación en sistemas distribuídos. E ese é o diff de hoxe. Son Niko de Axrisi. Fusionar con responsabilidade.

Fontes

  1. Idempotent requestsStripe Docs
  2. Designing robust and predictable APIs with idempotencyStripe Engineering — Brandur Leach
  3. Advanced error handlingStripe Docs
  4. HTTP Semantics — RFC 9110 §9.2.2 Idempotent MethodsIETF / RFC Editor

Vídeos relacionados