Revalidar el estado tras una decisión de Jev y antes de un efecto secundario

Objetivo

Evitar que una decisión sobre un estado anterior de la aplicación se aplique a ciegas cuando el registro, los permisos o la política relevantes han cambiado.

Requisitos previos

Defina las precondiciones de la acción, la fuente de la autoridad vigente y una revisión o huella (fingerprint) de los datos que se entregan al modelo. Mantenga las comprobaciones de control de acceso en la aplicación que realmente ejecuta la operación.

Pasos

1. Construya un paquete de estado acotado que contenga la revisión del registro relevante y la versión de la política. Registre qué datos influyen en la decisión; una huella calculada sobre campos no relacionados provoca invalidaciones evitables.

2. Evalúe la pregunta concreta y valide la decisión devuelta. Conserve junto a ella la revisión evaluada, en lugar de quedarse solo con una etiqueta de acción que pierde su contexto temporal.

3. Exija que el servicio autoritativo compruebe la revisión y los permisos relevantes de forma atómica junto con la mutación, mediante el mecanismo de escritura condicional o de transacción que ofrezca. Rechace la operación si no se cumple alguna precondición requerida; una lectura previa por sí sola deja abierta una condición de carrera.

4. Cuando el estado difiera, reconstruya el paquete y reconsidere la decisión dentro de una política de reintentos acotada. No interprete una respuesta obsoleta como aprobación para un objeto que ha cambiado recientemente o para un alcance ampliado.

5. Pruebe la retirada de un permiso, la actualización de una política, la sustitución de un registro y una edición concurrente entre la evaluación y la ejecución. Verifique que el consumidor se detiene o vuelve a evaluar en lugar de aplicar la decisión antigua.

Resultado esperado

La operación queda claramente vinculada a los datos que la justificaron y cuenta con una comprobación, a nivel de aplicación, de que esos datos siguen siendo válidos. Las decisiones obsoletas pasan a ser resultados explícitos que se pueden inspeccionar y reintentar de forma deliberada.

Límites y base de verificación

Este es un protocolo de aplicación sin probar. TypeSafe define el estado como el material que evalúa una solicitud; no bloquea los registros del llamador. Una nueva lectura por separado es solo orientativa: otro cambio puede producirse antes de la escritura. Para preservar el invariante se necesita una imposición atómica en el servicio autoritativo. La interfaz o el patrón subyacente se describe en State; el flujo de trabajo anterior es una adaptación propuesta.