Une limite cachée de 50 octets sur les motifs LIKE de SQLite a provoqué le plantage de Cloudflare Workers lorsque le projet Agentic Inbox a tenté de rechercher de longs objets d'e-mail, et le fait de tronquer les chaînes de recherche à 48 caractères a mis fin aux échecs.
Ce qui a cassé l'environnement d'exécution edge
Agentic Inbox exécute chaque boîte de réception à l'intérieur d'un Cloudflare Durable Object, en utilisant une base de données SQLite intégrée pour le stockage. L'agent piloté par l'IA construit un motif de recherche sous la forme %search_term%. SQLite impose un plafond strict de 50 octets sur la longueur totale d'un motif LIKE. Lorsqu'un utilisateur saisissait un objet de plus de 48 caractères, les symboles % environnants poussaient le motif au-delà de ce plafond. SQLite a renvoyé une erreur d'exécution non gérée, que l'environnement Worker restreint a traitée comme fatale. L'intégralité du script s'est interrompue, rendant la boîte de réception inutilisable et l'agent IA hors service.
Comment le bug a été découvert
Sentry a enregistré les exceptions non interceptées provenant des Workers. Lorsque le plantage est apparu, Sentry a enregistré la ligne exacte où SQLite a généré une erreur. Sa fonctionnalité « Seer AI » a analysé la trace de la pile, a mis en évidence la construction du motif LIKE et a suggéré que la longueur du motif était la coupable. Un coup d'œil rapide à la documentation de compilation de SQLite a confirmé la restriction de 50 octets, et l'équipe a utilisé Gemini pour vérifier la limite et calculer une longueur maximale sécurisée pour la saisie de l'utilisateur.
Le correctif chirurgical
La résolution a nécessité trois changements mineurs, tous situés à l'intérieur de la routine de recherche existante :
- Imposer une limite stricte de 48 caractères sur tout terme de recherche entrant.
- Découper la chaîne de saisie à cette longueur avant de concaténer les caractères génériques
%. - Laisser le reste de la requête inchangé, préservant ainsi la précision de la recherche sans ajouter de nouvelles bibliothèques.
Comme l'ajustement intervient avant que la requête n'atteigne SQLite, le motif final ne dépasse jamais le seuil de 50 octets, et le Worker ne plante plus. Aucune dépendance supplémentaire n'a été ajoutée, la base de code reste donc légère.
Pourquoi c'est important
Les bases de données hébergées en périphérie (edge) sont attrayantes pour les cas d'utilisation à faible latence, mais elles héritent des mêmes contraintes que les versions sur site (on-premises). Une limite obscure lors de la compilation peut devenir un bug bloquant en production lorsqu'un environnement d'exécution traite toute exception non gérée comme fatale. Ici, le plantage a empêché un assistant de messagerie piloté par l'IA de fonctionner pour tout utilisateur saisissant un objet de message long — un impact direct sur l'expérience utilisateur et sur la promesse de fiabilité des plateformes serverless.
Ce qui aurait pu être fait différemment
Le correctif est simple, mais il met en évidence une étape de validation manquante. Un assainissement des entrées (input sanitization) qui vérifie la longueur du motif avant de construire la chaîne SQL aurait permis de détecter le problème lors du développement plutôt qu'en production.
Ce qu'il faut surveiller à l'avenir
Les développeurs déployant SQLite sur des environnements d'exécution edge devraient auditer toutes les constructions de requêtes impliquant une recherche par motif, en particulier celles qui ajoutent des caractères génériques ou des caractères d'échappement. Sentry a capturé la ligne exacte où SQLite a échoué. À mesure que l'edge computing gagne du terrain, les limites cachées des plateformes apparaîtront plus souvent, et l'habitude de valider les entrées par rapport aux contraintes documentées portera ses fruits.
À retenir : Un plafond de 50 octets sur les motifs LIKE de SQLite peut faire planter Cloudflare Workers, mais le fait de tronquer les termes de recherche à 48 caractères élimine le défaut sans aucun surpoids — la preuve qu'une petite étape de validation peut maintenir la stabilité des services edge.
