Resumen

  • ifUnchangedBy permite que una escritura dependa solo de las propiedades relevantes, incluso en otro objeto del mismo tipo, sin bloquearse por toda modificación concurrente.
  • Esa precisión reduce conflictos espurios y a la vez estrecha la prueba: una condición satisfecha no demuestra que el objeto completo permaneció igual ni que la acción estaba autorizada en sentido empresarial.

La carpeta d3 tenía un permiso compartido para Bob. El cliente había leído shareWith/bob/mayRead:true y quería retirar esa entrada. Antes de enviar el cambio, otro dispositivo renombró la carpeta. Con una señal de estado para todo el tipo, aquella modificación podía invalidar el intento aunque no alteraba el derecho que motivaba la decisión.

La aplicación no necesitaba saber que todo seguía igual. Necesitaba saber una cosa: Bob todavía tenía exactamente el permiso observado. Si esa condición se mantenía, borrar su entrada era coherente con la decisión original; si no, el cliente debía releer y reconsiderar.

La revisión 00 de JMAP Conditional Set formaliza esa diferencia. Está fechada el 15 de septiembre de 2026, expira el 19 de marzo de 2027 y, al cierre de la investigación, era un Internet-Draft activo del grupo JMAP, previsto para Standards Track y para actualizar RFC 8620 si llegaba a aprobarse. No es un RFC final ni evidencia de despliegue o conformidad de producto.

JMAP Core ya ofrece ifInState, pero su cadena representa el estado de todo un tipo de objeto dentro de la cuenta. Cualquier cambio del tipo puede modificarla. En cuentas con correo entrante, varios dispositivos y procesos del servidor, una escritura sobre un solo objeto puede fracasar por actividad que no guarda relación con la propiedad que importa.

El nuevo argumento ifUnchangedBy expresa una condición como PatchObject. Cada identificador señala un objeto y cada puntero declara el valor esperado. La condición se cumple cuando aplicar ese PatchObject sobre la representación actual no cambiaría nada. null afirma que una propiedad no existe.

Elegir menos evidencia exige decir menos

La ventaja operacional es evidente. El cliente puede ignorar cambios concurrentes que ha decidido considerar irrelevantes. El cambio de nombre no impide retirar el permiso de Bob. Una modificación del derecho de otra persona tampoco tiene por qué intervenir. Solo el puntero elegido controla la decisión.

La consecuencia probatoria suele olvidarse. La respuesta positiva no dice «el objeto seguía igual». Dice «los valores seleccionados coincidían al comienzo del método». Las propiedades no seleccionadas pueden haber cambiado. El contexto fuera del modelo puede ser distinto. Incluso la política que justificó retirar el acceso puede haber sido revocada sin que el objeto lo refleje.

Una plataforma de auditoría que guarda únicamente “precondición aprobada” amplía el recibo. Debe conservar identificador, punteros, representación esperada, visibilidad y momento de evaluación. Sin ese contexto, una prueba deliberadamente estrecha se transforma en una versión imaginaria del objeto entero.

El proyecto permite reconstruir una comparación global si el tipo posee un token mantenido por el servidor que cambia con toda modificación. Una marca changed puede servir. Pero la sintaxis no garantiza la disciplina del token. Si una ruta administrativa, una migración o una reparación omite actualizarlo, el compare-and-swap acepta una historia incompleta.

La propiedad intelectual de la solución no está en pronunciar “optimistic concurrency”. Está en definir qué realidad concreta representa el token y demostrar que cada escritor la respeta.

La condición puede incluir el contexto próximo

La evaluación ocurre contra el estado al inicio del método, antes de aplicar sus propias creaciones, actualizaciones o destrucciones. También puede referirse a un objeto del mismo tipo que no será modificado. Así, un archivo puede cambiar de contenido solo si continúa bajo el padre d3 y ese padre conserva el nombre Reports.

Esa posibilidad protege contra una carrera sutil: el contenido correcto colocado en un lugar inesperado. Sin embargo, dos condiciones no forman automáticamente una política completa. Puede haber un abuelo movido, una retención legal, un montaje externo o una decisión de negocio no expresada en las propiedades.

El modelo sano trata cada puntero como evidencia de una proposición nombrada. No lo usa como sustituto universal de la autoridad sobre el activo.

Las condiciones pueden leer propiedades establecidas por el servidor que el cliente no puede modificar, como tamaño, identificador de contenido o tiempo de cambio. Pero solo si el cliente tiene derecho a leerlas. El servidor debe responder forbidden cuando la propiedad es invisible. Evaluarla y devolver simplemente éxito o fracaso permitiría adivinar secretos mediante preguntas binarias.

La autorización de lectura tampoco concede autorización de escritura. La mutación puede fallar por permiso aunque todos los valores coincidan. El dato observado no firma la orden.

El fallo de una condición detiene todo el método

Si alguna condición no se cumple, el servidor devuelve stateMismatch a nivel de método y no ejecuta ninguna creación, actualización ni destrucción del Foo/set. La cadena de estado permanece intacta. Puede enumerar los identificadores que fallaron, sin revelar los valores actuales.

El cliente que desea resultados independientes debe separar las operaciones en llamadas distintas. Esta elección define la unidad de destino. Agrupar cinco cambios significa aceptar que una divergencia detenga los cinco. Separarlos significa aceptar que algunos sean visibles antes que otros.

No hay una respuesta protocolaria única. La aplicación debe conocer el daño de la aplicación parcial. La capa común ofrece controles; no puede fabricar el juicio económico que decide cómo agruparlos.

Atomicidad es otra pregunta

El proyecto añade además atomic:true. JMAP Core puede procesar por separado las creaciones, actualizaciones y destrucciones de un método. Con la opción atómica, todas deben comprometerse como una unidad o ninguna.

Las restricciones se evalúan sobre el conjunto final. Esto permite intercambiar dos nombres únicos: el primer cambio aislado chocaría con el segundo, pero el resultado conjunto no tiene duplicado. Si cualquier parte falla—por parche inválido, colisión, permiso u otro error—el servidor devuelve atomicFailure y no compromete nada.

Una condición falsa sigue produciendo stateMismatch. La distinción es útil. En un caso el punto de partida dejó de ser el esperado; en el otro, las mutaciones propuestas no pudieron formar una unidad válida.

Cuando el servidor no puede ofrecer atomicidad para el método, debe devolver cannotApplyAtomically. Tiene prohibido aplicar solo una parte. Este rechazo mantiene visible la frontera de capacidad. Un reintento sin atomic es permitido únicamente si el cliente puede tolerar el resultado parcial.

Ese reintento debilitado debe aparecer como una decisión nueva. Si el software lo ejecuta automáticamente ante presión, transforma un invariante declarado en una preferencia opcional. La disponibilidad habrá ganado ocultando qué consistencia se sacrificó.

Un commit limpio no completa el mundo

La atomicidad termina en el Foo/set que el servidor acepta. No incluye por defecto índices, notificaciones, cachés, réplicas, agentes desconectados o servicios remotos. Retirar un permiso en la base de objetos no prueba que un enlace ya emitido haya dejado de funcionar. Intercambiar nombres no prueba que un caché de rutas muestre la nueva relación. Destruir un mensaje no borra una copia local fuera de línea.

Por eso la cadena de recibos debe separar: principal autenticado, mandato empresarial, valores condicionados, resultado del método, lectura posterior, generación consumida por cada subsistema y efecto visto por el usuario. Llamar a todos “éxito” convierte una secuencia observable en una fe administrativa.

La doctrina de Heng Lu pide que la coordinación permanezca delgada. El mecanismo puede comparar propiedades y proteger una unidad de commit. No debe asumir soberanía sobre las consecuencias. El operador sigue siendo responsable de decidir qué significa el cambio y qué prueba completa la acción.

El ensayo de producción debe buscar afirmaciones negativas. Cambie una propiedad no seleccionada y confirme que la condición estrecha continúa. Cambie el puntero seleccionado y compruebe que no se filtra ninguna mutación. Pruebe una propiedad oculta y exija forbidden. Provoque un fallo en una parte atómica y verifique que las demás tampoco aparecen. Retrase cada consumidor externo después del commit.

La condición comprobó un permiso. Esa precisión evitó un conflicto falso. La honestidad consiste en no convertirla después en prueba de todo el objeto, de todo el derecho o de todo el resultado.

Fuentes