Prevuelo y Compromiso Inverso
La validación previa al vuelo te permite verificar un commit sin mutar el estado del mundo. El commit inverso te permite compensar un commit anterior emitiendo un nuevo commit derivado del plan inverso almacenado en el sidecar de deshacer. Ambos están diseñados para preservar la reproducción determinista y el contrato de un solo escritor.
Problema que este concepto resuelve
Los sistemas complejos necesitan dos capacidades que son fáciles de malutilizar:
- Valida planes de múltiples pasos sin tocar el estado de producción.
- Compensar los cambios comprometidos sin reescribir el historial.
La verificación previa y el compromiso inverso proporcionan estas capacidades mientras mantienen el registro de compromisos autoritativo y seguro para la reproducción.
Ideas principales
Validación previa al vuelo
Preflight ejecuta la misma lógica L2/L3 que un compromiso real, pero se ejecuta en un entorno aislado, por lo que no hay mutaciones, no se añade un registro de compromiso y no hay emisiones de observadores.
Propiedades clave:
- Resultados equivalentes a commit utilizando el mismo orden de operaciones.
- Semántica de fallo rápido (el primer fallo termina la validación).
- Salida determinista para un estado mundial dado.
- Devuelve
validated_world_seqpara que los clientes puedan coordinar la concurrencia optimista. - No hay mutación de estado, no hay adición de registro, no hay emisiones de observador.
La salida está vinculada a la secuencia mundial en el momento de la validación. Si se realizan nuevos commits antes de que envíes el commit real, vuelve a ejecutar preflight para confirmar que el plan sigue vigente.
Utiliza preflight cuando necesites verificar un plan, horario o secuencia multi-op antes de emitir el compromiso real.
Revertir compromiso
El commit inverso es una escritura regular que carga un plan inverso almacenado desde el sidecar de deshacer. El plan se construye en el momento del commit a partir del registro de deshacer más el estado posterior del commit, y se aplica como un nuevo commit solo si el estado actual aún coincide con el estado posterior esperado del plan. No reescribe la historia ni elimina eventos anteriores.
Propiedades clave:
- Utiliza
commit_idcomo el identificador externo para la reversión. - Requiere un motivo de auditoría y carga una entrada de lado de deshacer para el compromiso objetivo.
- Valida el estado actual contra el estado posterior esperado del plan (capturado en el momento del commit) antes de aplicar el plan inverso.
- Falla en cerrado si la entrada de deshacer está ausente o ha expirado.
- Emite una respuesta de commit normal con nuevos metadatos de secuencia.
Revertir el commit más reciente suele ser sencillo porque el estado actual aún coincide con el estado posterior esperado del plan. Revertir commits históricos es condicional: otros commits pueden haber movido o eliminado activos, llenado contenedores o cambiado restricciones de clase. El plan de reversión falla ante esos conflictos.
El commit inverso es mecánico: aplica el plan almacenado o falla. Si tiene éxito contra un mundo cambiado, refleja los pasos de deshacer almacenados aplicados al estado actual, no el deshacer a nivel de intención. Si necesitas deshacer una historia más profunda, planifica un commit compensatorio y prévia contra el estado actual.
Deshacer disponibilidad del sidecar
El commit inverso solo funciona si el sidecar de deshacer está habilitado y el commit objetivo aún se encuentra dentro de la política de retención. La disponibilidad depende de la configuración de implementación y la gobernanza del espacio de nombres. Si el sidecar está deshabilitado o la entrada es eliminada, el commit inverso debe fallar de manera cerrada.
Cómo encaja en el sistema
Commit request -> Preflight (optional) -> Commit -> Commit log append
Reverse commit request -> Load reverse plan -> Validate post-state -> Compensating commit (if valid) -> Commit log append
El preflight es una ruta de validación; el reverse commit es una ruta de escritura compensatoria. Ambas pasan por el daemon de escritura y deben respetar las reglas de autorización, cuota y política.
Invariantes clave y garantías
Validación no mutante
Preflight nunca cambia de estado, nunca añade al registro y nunca emite observadores. Es seguro para la planificación y la automatización.
Historial de solo anexado
La reversión de un commit añade un nuevo commit. El commit original permanece en el registro y en la auditoría.
Deshacer con fallo cerrado
Si los datos de deshacer están ausentes o han expirado, se deniega la reversión. No se permiten reversibles parciales.
Autorización explícita
La reversión de un commit es una operación distinta y está sujeta a control de acceso basado en roles (RBAC). Las razones de auditoría se registran con la reversión del commit.