Una aprobación se corrigió a Declined: cómo probar la revocación de permisos

El problema: una aprobación que ya no vale

Un vendedor superó la verificación, tu handler registró Approved y la política explícita permitió un permiso local. Después llega un nuevo evento Declined para la misma sesión. Si tu código trata todo estado terminal como definitivo, ignora la corrección y el acceso sigue abierto. Si trata cada evento entrante como nuevo, un callback repetido puede hacer que el estado cambie de un lado a otro. El objetivo es concreto. Una nueva corrección Declined posterior a Approved debe cambiar permission_granted de true a false. grant_count debe seguir en 1, porque el historial de la concesión no desaparece. Los eventos duplicados y obsoletos no deben cambiar nada. Si un proveedor real envía este tipo de correcciones, y qué significan, depende de su contrato real. El fixture solo permite ensayar la estructura.

Qué implementa realmente el fixture

El ejemplo de identidad descargable guarda en SQLite las sesiones y los IDs de eventos procesados. Su método event solo acepta mode synthetic_fixture y source fixture_callback, y solo IDs de evento que empiezan por fixture-. No tiene verificador de firmas de producción. Primero comprueba la vinculación de tenant y subject, y después deduplica por el par sesión e ID de evento. Una sola regla gestiona las correcciones. Si el estado guardado es approved y llega Declined, el fixture registra el evento y pone status en declined y granted en 0. El contador grants no se modifica. Cualquier otro evento sobre una sesión approved, declined o expired devuelve el estado actual sin cambios. Ese evento tampoco se registra. Esta comprobación de corrección se ejecuta antes de la del plazo, así que una corrección Declined posterior a Approved se aplica aunque llegue después del plazo. live_permission_changed siempre es false. No existe ningún permiso real.

Escenario hipotético y salidas esperadas

Este es un recorrido hipotético sobre fixture-session, vinculada a fixture-tenant y fixture-user, con deadline 60. Paso 1: envía el evento fixture-approved con status Approved y policy true. Se espera status approved, deadline 60, permission_granted true, grant_count 1 y live_permission_changed false. Paso 2: repite fixture-approved. Se espera el mismo objeto. El duplicado no tiene efecto. Paso 3: envía un ID de evento nuevo, por ejemplo fixture-correction, con status Declined. Se espera status declined, deadline 60, permission_granted false, grant_count 1 y live_permission_changed false. La salida probada expired corresponde a otra ruta: una sesión que nunca recibió aprobación. Tiene status expired, permission_granted false, grant_count 0, next review_or_authorized_provider_refresh y provider_polled false. No la uses como prueba de revocación.

Corrección nueva, duplicado o evento pendiente obsoleto

Tres entradas pueden parecer iguales y deben mantenerse separadas. Una corrección nueva trae un ID de evento no visto y status Declined sobre una sesión approved. Revoca el permiso. Un duplicado reutiliza un ID ya procesado. Devuelve el estado guardado, aunque su campo status sea distinto. Un evento pendiente obsoleto, como In Progress o In Review después de Approved, no debe degradar ni volver a conceder nada. El fixture devuelve el estado actual y no lo registra. Otros dos casos siguen la misma regla. Un Approved tardío después de la corrección Declined también se ignora, así que el permiso no se reabre en silencio. Un segundo Declined tras declined no cambia nada. Prueba cada caso con IDs distintos y comprueba tanto permission_granted como grant_count.

Diseño propuesto: un recibo de revocación propiedad del llamador

Lo siguiente es un diseño propuesto, no comportamiento del fixture. El fixture solo cambia un indicador; una revocación real afecta a anuncios, pagos o sesiones en sistemas que controlas tú. Un recibo de revocación propiedad del llamador podría registrar: - la sesión - el ID del evento que corrige - el estado anterior y el nuevo - el contador de concesiones en el momento de la revocación - una marca de tiempo - qué acciones posteriores se solicitaron y cuáles se confirmaron Escribe el recibo en la misma transacción que retira el permiso. Haz que los pasos de reversión posteriores sean idempotentes respecto a ese recibo. Antes de confiar en una corrección, vuelve a obtener la decisión autoritativa mediante una ruta de proveedor autorizada. Un Declined sintético no prueba un rechazo real, y un permiso sintético del fixture no es un permiso de negocio real.

Gestión de fallos

Varios fallos necesitan un comportamiento definido. Si una corrección no supera la comprobación de vinculación, el fixture lanza BINDING_MISMATCH. Trátalo como una alerta, no como una revocación. Las fuentes no sintéticas lanzan PRODUCTION_SIGNATURE_VERIFIER_NOT_IMPLEMENTED. Los IDs sin el prefijo fixture- lanzan SYNTHETIC_EVENT_REQUIRED. Enviar un evento a una sesión inexistente lanza BINDING_MISMATCH; leer una sesión inexistente con read lanza SESSION_NOT_FOUND. El método recover solo hace expirar localmente sesiones pending, review o unknown. Nunca consulta al proveedor ni revierte una aprobación. No confíes en él para detectar una corrección perdida. Si la revocación posterior falla parcialmente, mantén el permiso retirado y marca el recibo como incompleto para revisión. No restaures el acceso.

Lista de aceptación

- Approved con policy true produce permission_granted true y grant_count 1. - Repetir el ID del evento de aprobación no cambia ninguno de los dos campos. - Un nuevo Declined produce status declined, permission_granted false y grant_count 1. - Un In Progress o In Review obsoleto tras Approved no cambia nada. - Un Approved tardío tras la corrección no restaura el permiso. - Se rechaza una corrección con tenant o subject incorrectos. - live_permission_changed permanece en false en todo momento. - Tu propio recibo y los pasos de reversión posteriores se prueban por separado. - La semántica de corrección se confirma con el contrato del proveedor real antes de cualquier uso real.

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/approved-seller-permissions/ 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.