Le Bug Qui se Cachait dans la Couche de l'API

La vue de la table a chargé. Le canvas a rendu. La table existait dans la base de données.

Mais quand le front-end a demandé au serveur l'état actuel de la table — les sièges, les stacks, qui est assis où — le serveur a renvoyé un 404. Rien. Pas de sièges, pas de données de jeu, rien avec quoi le renderer pouvait travailler.

Le canvas était vide parce qu'il n'avait rien à dessiner.

Voici l'explication technique, gardée aussi courte que possible : l'API gateway devant le table engine retire un préfixe de chaque URL avant de transférer la request. /api/v1/tables/... arrive au table engine comme /tables/.... Les routes du table engine, telles qu'écrites par la session de build, ont été enregistrées en attendant le préfixe complet — donc le serveur écoutait sur /api/v1/tables/... mais recevait /tables/.... Chaque request ratait.

Pas une erreur de logique. Pas un algorithme cassé. Une table de routing avec les mauvaises adresses. Le genre de chose qui n'émerge que quand tu testes la stack complète ensemble.

Combien de Temps a-t-il Fallu pour le Trouver ?

Du début au fix : moins d'une heure.

C'est rapide. Voici ce qui l'a rendu rapide : la méthodologie de debugging.

Travailler avec un agent AI sur ça ne veut pas dire demander "qu'est-ce qui ne va pas ?" et espérer une réponse. Ça veut dire donner à l'agent le bon contexte simultanément — la configuration du proxy qui gère le préfixe, les fichiers d'enregistrement de routes dans le table engine, les logs de requests montrant le 404 — et lui demander de tracer la discrepancy.

Quand ces pièces sont visibles ensemble, l'agent peut faire du pattern-matching sur une surface qui prendrait à un ingénieur humain vingt minutes juste pour naviguer. L'agent a trouvé le mismatch entre la règle de rewrite du proxy et l'enregistrement de route dans le table engine en environ trois minutes.

Le Bug Derrière le Bug

Trouver le bug de routing a exposé le suivant.

L'endpoint répondait maintenant. Mais les données qu'il renvoyait étaient dans le mauvais format.

Le table engine parle une langue en interne : numéros de siège, codes de statut comme occupied, comptes de jetons bruts comme des entiers simples. Le renderer front-end parle une autre : indexes de siège, chaînes de currency formatées comme $235.50, noms de champs spécifiques qu'il attend par contrat depuis une définition de type contre laquelle il a été écrit.

Personne n'a écrit de couche de traduction. La session de build a écrit l'endpoint et il a renvoyé le format interne. Le renderer a reçu des données qu'il ne reconnaissait pas et a silencieusement produit rien.

C'est la classe de bug pour laquelle il est notoirement difficile d'écrire un test à l'avance. Tu dois avoir les deux systèmes qui tournent, connectés, et qui essaient de se parler pour le voir. Aucun unit test ne couvre l'écart entre deux systèmes quand aucun des systèmes n'a de bug par lui-même.

Ce Que Cela Signifie pour la Méthodologie de Build

La phase de testing ne signifie pas que la méthodologie a échoué. Elle signifie que la méthodologie nous a amenés au testing.

Chaque plateforme logicielle a une couche d'intégration où les pièces doivent se rencontrer dans le monde réel. Le développement spec-driven te mène à cette couche plus vite. Il ne la saute pas.

Le prochain post de cette série couvre ce qui s'est passé quand nous avons appliqué les corrections — et le browser a quand même montré le même résultat cassé.

Pour la méthodologie d'ingénierie derrière notre façon de construire — le spec, les sessions, ce que fait l'agent pendant une session et ce que fait l'architecte — l'écrit complet est sur The Salty Korean.

Stay salty.