Tiempo de espera, rechazo y ruta no soportada: tres resultados distintos

El problema y la decisión que le corresponde

Imagine un servicio de alta de vendedores que necesita un resultado de identidad antes de habilitar una función de pagos. Tres llamadas fallan de tres maneras distintas. La primera nunca se completa porque el proveedor no está disponible. La segunda se completa y el proveedor responde Declined. La tercera pide una capacidad que la ruta no ofrece, como enviar un OTP desde una comprobación telefónica. Si un único manejador convierte los tres casos en rechazo, los usuarios honestos quedan bloqueados cada vez que el proveedor cae. Si los convierte en permiso, una caída se transforma silenciosamente en aprobación. La guía de GridZen lo dice con claridad: un proveedor no disponible es un fallo operativo, no una señal de bajo riesgo. Su adaptador actual de Twilio devuelve un 503 a través de la API cuando el proveedor no está disponible. La versión alfa no convierte ese fallo en permiso de forma silenciosa. La decisión que le corresponde es qué hace su flujo después en cada resultado. Una cola de revisión, una retención o una alternativa aprobada explícitamente deben implementarse en el flujo que realiza la llamada.

Una tabla de decisión propuesta, propiedad del llamador

Esto es un diseño de aplicación propuesto, no un comportamiento implementado por GridZen. Cada fila debe indicar la clase de resultado, su evidencia, el estado HTTP registrado y la siguiente acción. Fallo técnico: la comprobación no pudo completarse, por ejemplo por un tiempo de espera agotado, una respuesta malformada, credenciales ausentes o un 503. No es evidencia sobre la persona. Siguiente acción: retener el flujo, aplicar un reintento acotado solo si la operación upstream y su flujo lo permiten, y después enviar a revisión. Evidencia negativa: el proveedor completó la comprobación y devolvió una afirmación, como Declined o una discrepancia. Siguiente acción: aplicar su política de rechazo, mantener el registro explicable y no reintentar con la esperanza de obtener otra respuesta. Evidencia insuficiente: la política carece de una señal requerida, por ejemplo un resultado desconocido. Siguiente acción: revisión, o un paso que usted ya ejecute. Ruta no soportada: la capacidad nunca se solicitó a un proveedor. Siguiente acción: usar otro proveedor que usted haya autorizado para esa tarea. Registre el estado HTTP por separado del resultado de la decisión. Un 503 no tiene una respuesta de decisión exitosa y nunca debe registrarse como rechazo ni como permiso. La tabla tampoco contiene ninguna fila que envíe la solicitud a otro proveedor por sí sola. Una alternativa solo es aceptable si alguien la aprobó explícitamente para esa tarea y esos datos.

Escenario hipotético con salidas del fixture

De forma hipotética, un equipo aplica su tabla al ejemplo telefónico descargable de cuatro ramas y al fixture de identidad. Este es el ejemplo local. No es la prueba HTTP anónima de tres escenarios, que es algo distinto. Las ramas telefónicas muestran las clases lado a lado. Todas devuelven mode synthetic_fixture, otp_sent false y live_line_type_available false. La rama normal devuelve state simulated, valid true, line_type mobile y next continue_customer_policy. La rama unknown devuelve state unknown, valid null, line_type null y next review_or_existing_otp. Eso es evidencia insuficiente. La rama provider_failure devuelve state unknown, valid null, line_type null y next bounded_retry_then_review. Eso es un fallo técnico, y su siguiente paso difiere del de la rama unknown aunque el campo state coincida. Por eso su tabla debe basarse en la causa y no solo en el campo state. La rama otp devuelve state unsupported, valid null y next customer_otp_provider. Es una ruta no soportada, y no se envía ningún mensaje. En el lado de identidad, una corrección sintética a Declined después de una aprobación devuelve status declined, permission_granted false y grant_count 1. Eso es evidencia negativa y se registra como rechazo. No es una caída del proveedor.

Manejo de fallos en el fixture de identidad

El fixture de identidad muestra cómo una comprobación incompleta no debe derivar en un resultado. Si no llega ninguna decisión antes del plazo, recover marca la sesión como expirada localmente. Con deadline 60, la salida es status expired, permission_granted false, grant_count 0, next review_or_authorized_provider_refresh y provider_polled false. Recover no consulta a ningún proveedor. Solo expira las sesiones pending, review o unknown cuyo plazo ya venció. Un estado no reconocido pasa a unknown, no a declined. Los errores también son distintos. Un evento para una sesión desconocida genera BINDING_MISMATCH, y leer una sesión desconocida genera SESSION_NOT_FOUND. Los eventos del fixture solo aceptan callbacks sintéticos con origen fixture. Un modo o un origen que no sea del fixture genera PRODUCTION_SIGNATURE_VERIFIER_NOT_IMPLEMENTED, porque no existe un verificador de firmas real. Los eventos duplicados mantienen grant_count en 1. Cualquier valor de permission_granted es un registro local del fixture, con live_permission_changed false. No es un permiso de negocio real.

Límites: implementado frente a propuesto

El fixture implementa las cuatro ramas telefónicas, los estados de sesión en SQLite, la expiración local, la deduplicación y los nombres de error anteriores. Según la guía, la API alfa implementa un 503 cuando el proveedor del adaptador de Twilio no está disponible. La tabla de decisión, la cola de revisión, el presupuesto de reintentos y cualquier alternativa aprobada son diseño suyo. La alfa de GridZen no mueve fondos ni garantiza la idempotencia de una acción de pago posterior. La ruta telefónica gratuita actual no solicita tipo de línea, titularidad, alcanzabilidad ni entrega de OTP. En la incorporación de identidad alojada, sigue sin probarse que una persona nueva complete el recorrido alojado completo, y Approved no es un permiso incondicional. La disponibilidad de rutas en vivo requiere una confirmación aparte.

Lista de aceptación

Use esta lista antes de dar la tabla por terminada. Cada clase de resultado tiene su propia fila, con la siguiente acción por escrito. El estado HTTP y el resultado de la decisión se guardan en campos separados. Un 503 o un tiempo de espera agotado nunca se registra como rechazo ni como permiso. Los reintentos son acotados y solo se permiten cuando la operación upstream lo admite. Ninguna ruta de código cambia de proveedor por sí sola, y cualquier alternativa está aprobada explícitamente. Las pruebas cubren tiempo de espera, respuesta malformada, credenciales ausentes, rechazo del proveedor y recuperación, y coinciden con las salidas del fixture descritas arriba. Las sesiones expiradas muestran provider_polled false y llevan a revisión. Los permisos sintéticos nunca se conectan con permisos reales. Los mismos casos se revisan de nuevo cada vez que se habilita un proveedor o una política nueva. Cuando todo esto pase en local, decida si una solicitud de sandbox guardada encaja con su tarea.

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.sqlite

Fuentes y alcance

https://gridzen.ai/guides/provider-failures/ 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.