La respuesta HTTP se envió, pero el flujo sigue en ejecución: mantenga honesto el estado de verificación
Un issue público de n8n describe un flujo con webhook que ya devolvió una respuesta HTML exitosa mientras su ejecución, que incluye un nodo PostgreSQL, sigue apareciendo como en curso. No podemos diagnosticar ni corregir ese problema del proveedor, y no representamos a nadie afectado por él. Sin embargo, plantea una pregunta adyacente para los equipos que integran onboarding de identidad. Cuando la capa HTTP indica que terminó pero el trabajo de fondo no ha concluido, ¿qué debe creer su aplicación sobre una sesión de verificación? Este artículo responde con el fixture sintético verification_delivery. El objetivo es ayudarle a decidir si una integración sandbox encaja con su tarea.
curl https://gridzen.ai/console/api/quickstart/trial \
-H 'Content-Type: application/json' \
-d '{"task": "identity_onboarding", "scenario": "success"}'El problema y su decisión
Una respuesta 200 solo le dice al emisor que la solicitud se recibió. No le dice que la escritura en la base de datos se confirmó, que se registró una decisión ni que cambió un permiso. Si un manejador de callbacks responde y luego se bloquea, hay tres resultados posibles: el estado de la sesión puede quedar desactualizado, la actualización puede quedar a medias o puede llegar un callback reintentado. Su decisión es dónde reside la verdad. Recomendamos mantenerla en el estado persistido de la sesión, con una fecha límite, y nunca en el resultado HTTP ni en la existencia de una ejecución. Una sesión bloqueada o sin callback nunca debe convertirse en aprobación.
Lo que el fixture implementa realmente
El ejemplo descargable guarda sesiones y eventos en SQLite. El paso create registra una sesión pending con una fecha límite; el valor predeterminado es 60. El paso event hace cuatro cosas. Rechaza todo lo que no sea un fixture_callback sintético y lanza PRODUCTION_SIGNATURE_VERIFIER_NOT_IMPLEMENTED. Comprueba la vinculación de tenant y subject. Deduplica por ID de evento dentro de una sola transacción inmediata. Normaliza el estado. El paso recover marca como expired las sesiones pending, review o unknown una vez vencido el plazo. Se ejecuta localmente y no consulta a ningún proveedor. Toda lectura devuelve live_permission_changed: false. Un permiso concedido en el fixture es un registro local, no un permiso de negocio.
Escenario hipotético resuelto
Imagine que su manejador de callbacks respondió rápido, pero su paso de base de datos se colgó. Reinicia el servicio sobre el mismo archivo SQLite. Crear la sesión devuelve state simulated, un hosted_link bajo example.invalid, link_executable false y next send_real_provider_link_only_after_authorization. Un evento Approved sintético con política explícita devuelve status approved, deadline 60, permission_granted true y grant_count 1. Si el emisor reintenta el mismo evento, el resultado es idéntico: grant_count sigue en 1. Una corrección Declined posterior devuelve status declined y permission_granted false, mientras grant_count se mantiene en 1. En otra sesión donde nunca llega ningún callback, recover con now=61 devuelve: - status expired - permission_granted false - grant_count 0 - next review_or_authorized_provider_refresh - provider_polled false
Manejo de fallos que le corresponde
El fixture informa dos errores. Un evento de una sesión desconocida lanza BINDING_MISMATCH, y leer una sesión desconocida lanza SESSION_NOT_FOUND. Trate ambos como señales para investigar, no como motivos para reintentar a ciegas. Diseño de aplicación propuesto, que no está implementado aquí: - Confirme el estado antes de responder, o responda solo cuando el evento esté persistido de forma idempotente. - Genere alertas para las sesiones que siguen en pending cerca de su fecha límite. - Use reintentos acotados. - Envíe las sesiones expiradas a revisión o a una actualización de estado autorizada. Un sistema de producción también necesita validación de firmas específica del proveedor y una conciliación de estado acotada. El fixture no establece ninguna de las dos.
Límites que conviene decir claramente
Los eventos del fixture solo aceptan callbacks sintéticos, nunca firmas reales. Recover expira las sesiones localmente y nunca contacta a un proveedor. Una concesión sintética no es un permiso de negocio real, y Approved no es un permiso incondicional en ningún contexto. La guía también ofrece una breve prueba HTTP anónima, que es algo distinto del ejemplo descargable y sus pruebas de ramas. Que las pruebas pasen solo demuestra transiciones simuladas. No demuestra éxito en producción. La disponibilidad de rutas reales requiere confirmación aparte.
Lista de aceptación
- Las pruebas de reinicio y de recuperación por timeout pasan al reutilizar la misma base de datos. - Un evento duplicado no cambia grant_count. - Una corrección Declined deja permission_granted en false. - Una sesión expirada muestra provider_polled false y remite a revisión. - Se rechazan los eventos con vinculaciones desconocidas. - Ninguna ruta de código trata un HTTP 200 o una ejecución en curso como aprobación. - Su propio documento de diseño indica quién realiza la actualización autorizada y quién realiza la revisión.
Ejecutar el ejemplo sintético comprobado
Descargue y extraiga https://gridzen.ai/downloads/verification-delivery.zip, entre en verification_delivery y ejecute con Python 3.10+. El ejemplo local no hace llamadas de red. Use una base nueva para otra prueba de identidad.
python3 delivery.py identity --db /tmp/gridzen-article-fixture.sqliteFuentes y alcance
https://gridzen.ai/guides/missing-verification-webhook/ https://gridzen.ai/guides/current-capabilities/ Basado en las fuentes comprobadas y el ejemplo local; las reglas propuestas son recomendaciones de diseño, no comportamiento de producción demostrado. Redacción asistida por IA con revisión independiente.
Probar por separado tres resultados del sandbox Crear una cuenta para continuar la integración
Una descarga no demuestra una ejecución correcta. Los ejemplos locales y el sandbox en línea se prueban por separado.