L'application todo est le test canonique de tout framework web. Quand nous avons construit l'application todo de FLIN, l'interface se rendait magnifiquement. Les boutons cliquaient. Les formulaires se soumettaient. Et chaque donnée disparaissait au moment du rafraîchissement de la page.
Il a fallu trois sessions -- 201, 202, 203 -- réparties sur le 16 janvier 2026, pour tracer et corriger la chaîne de bugs empêchant les données d'atteindre le disque.
Session 201 a résolu quatre problèmes d'interactivité du navigateur : la liaison de données bidirectionnelle, la soumission de formulaires, les gestionnaires d'événements avec arguments et le point de terminaison /_action.
Session 202 a corrigé le problème d'architecture de persistance : chaque requête HTTP créait un VM::new() avec une base de données en mémoire vide. La correction a utilisé VM::with_storage() pour connecter à un stockage sur disque.
Session 203 a découvert trois causes racines pour un seul fichier WAL vide : le bytecode écrasant l'état injecté (corrigé avec des variables globales protégées), Value::Text non géré par Trim, et les validateurs causant des échecs silencieux.
Les trois couches d'architecture des bugs de persistance
| Couche | Bug | Symptôme |
|---|---|---|
| Injection d'état | Le bytecode écrase l'état injecté | La fonction reçoit des valeurs vides |
| Gestion des types | Value::Text non géré par Trim | La condition de garde échoue toujours |
| Validation | Les validateurs rejettent silencieusement | La sauvegarde n'atteint jamais la base de données |
Chaque couche empêchait indépendamment les données d'atteindre la base de données. Corriger seulement une ou deux n'aurait pas suffi.
La leçon plus large
La saga de persistance en trois sessions nous a appris que l'écart entre « les tests unitaires passent » et « l'application fonctionne » peut être énorme. Tous les 2 870 tests passaient tout au long de ce processus de débogage. Chaque composant, testé en isolation, était correct. Mais l'intégration -- la séquence spécifique d'opérations qui se produit quand un utilisateur tape un titre de tâche, appuie sur Entrée et s'attend à le retrouver demain -- traversait des frontières qu'aucun test individuel ne couvrait.
La correction de persistance n'était pas une solution élégante unique. C'étaient trois corrections séparées pour trois bugs séparés, découverts sur trois sessions couvrant une journée entière. C'était désordonné, itératif et sans glamour. C'était aussi absolument essentiel.
Ceci est la partie 162 de la série « Comment nous avons construit FLIN », documentant comment un CEO à Abidjan et un CTO IA ont conçu et construit un langage de programmation à partir de zéro.
Navigation de la série : - [161] Le bug de suivi des versions temporelles - [162] La correction de persistance qui a pris 3 sessions (vous êtes ici) - [163] Le bug d'enveloppement des enfants dans les layouts