El modelo temporal de FLIN es una de sus características más distintivas. Cada entidad mantiene automáticamente un historial de versiones, y los desarrolladores pueden navegar ese historial usando el operador @. user @ -1 recupera la versión anterior. user @ -3 retrocede tres versiones. Todo el historial se preserva en la base de datos, accesible con un solo carácter de sintaxis.
El 7 de enero de 2026, teníamos esta funcionalidad completamente implementada -- o eso pensábamos. El operador @ se analizaba, compilaba y manejaba por la VM. La base de datos almacenaba el historial de versiones correctamente. Las pruebas de integración habían sido escritas. Y sin embargo user @ -1 siempre devolvía None, sin importar cuántas versiones existieran.
El modelo temporal estaba completo en cada componente pero fallaba en la brecha entre ellos.
El problema de los dos mundos
La arquitectura de FLIN tiene una personalidad dividida en lo que respecta a las entidades. Una entidad existe simultáneamente en dos lugares: como un Value::Object en el heap de la VM, y como una fila en la base de datos ZeroCore. Estas dos representaciones deben mantenerse sincronizadas, pero tienen ciclos de vida diferentes.
Cuando creas una entidad en FLIN, la VM crea un EntityInstance en su heap con id = 0, version = 0 y los campos especificados. Cuando la guardas, la VM envía la entidad a la base de datos ZeroCore, que le asigna un ID, crea un registro de versión y almacena los campos.
El error estaba en lo que sucedía después: la copia de la VM de la entidad no se actualizaba con la información que la base de datos asignó. Después de guardar, la VM aún tenía version = 0 aunque la base de datos tenía version = 1.
Cómo la discrepancia de versiones rompía el acceso temporal
El operador de acceso temporal @ funciona calculando una versión objetivo a partir de la versión actual de la entidad y el desplazamiento solicitado:
target_version = entity.version + offsetPara user @ -1 (una versión atrás):
// Lo que debería pasar:
target_version = 2 + (-1) = 1 // Encontrar versión 1
// Lo que realmente pasaba:
target_version = 0 + (-1) = 0 // Usa resta con saturación: 0
// La base de datos no tiene versión 0
// Devuelve NoneLa corrección: la base de datos como fuente de verdad
La corrección siguió un principio simple: después de cualquier mutación, obtener la entidad de vuelta desde la base de datos y sincronizar todos los campos temporales.
rustmatch self.database.save(&type_name, entity_id, entity.fields.clone()) {
Ok(saved_id) => {
// Obtener la entidad actualizada de la base de datos
if let Ok(Some(saved_entity)) = self.database.find(&type_name, saved_id) {
if let Ok(obj) = self.get_object_mut(obj_id) {
if let ObjectData::Entity(e) = &mut obj.data {
e.id = saved_id;
e.version = saved_entity.version;
e.created_at = saved_entity.created_at;
e.updated_at = saved_entity.updated_at;
e.deleted_at = saved_entity.deleted_at;
}
}
}
}
Err(_e) => { /* manejo de errores */ }
}Con la versión correctamente sincronizada, el acceso temporal funcionó perfectamente. user @ -1 calculó target_version = 2 - 1 = 1, encontró la versión 1 en la base de datos y devolvió la entidad con name = "Alice".
El principio de sincronización
Este error cristalizó un principio de diseño que ahora gobierna todas las operaciones de entidades en FLIN: después de cualquier mutación de base de datos, sincronizar la representación de la entidad en la VM con la versión de la base de datos.
La base de datos es la fuente de verdad para IDs, números de versión, timestamps y estado de eliminación suave. La VM es la fuente de verdad para valores de campos siendo manipulados y cambios no confirmados.
El patrón refleja la semántica de transacciones de bases de datos: después de un commit, cualquier lectura subsiguiente debería ver los valores confirmados. Sin la sincronización, la VM operaba con metadatos obsoletos. El modelo temporal, que depende enteramente de números de versión correctos, fue la víctima más visible de esta obsolescencia.
Veinte líneas de código. Dos errores críticos corregidos. Todo el sistema de acceso temporal -- que es posiblemente la característica más innovadora de FLIN -- pasó de roto a funcional.
Esta es la Parte 161 de la serie "Cómo construimos FLIN", que documenta cómo un CEO en Abidjan y un CTO de IA diseñaron y construyeron un lenguaje de programación desde cero.
Navegación de la serie: - [160] Cuando la VM se bloqueó en la creación de entidades - [161] El error de seguimiento de versiones temporales (estás aquí) - [162] La corrección de persistencia de base de datos que tomó 3 sesiones