Der Bug, Der sich in Der API-Schicht Versteckte

Die Tisch-Ansicht lud. Das Canvas wurde gerendert. Der Tisch existierte in der Datenbank.

Aber als das Front-End den Server nach dem aktuellen Zustand des Tisches fragte — die Sitze, die Stacks, wer wo sitzt — gab der Server einen 404 zurück. Nichts. Keine Sitze, keine Spieldaten, nichts womit der Renderer arbeiten konnte.

Das Canvas war leer, weil es nichts zu zeichnen hatte.

Hier ist die technische Erklärung, so kurz wie möglich gehalten: Das API Gateway vor der Table Engine entfernt ein Präfix von jeder URL bevor es die Request weiterleitet. /api/v1/tables/... kommt an der Table Engine als /tables/... an. Die Routen der Table Engine, wie von der Build Session geschrieben, wurden registriert mit der Erwartung des vollen Präfixes — also lauschte der Server auf /api/v1/tables/... aber empfing /tables/.... Jede Request ging daneben.

Kein Logikfehler. Kein kaputter Algorithmus. Eine Routing-Tabelle mit den falschen Adressen. Die Art von Sache, die nur auftaucht, wenn du den kompletten Stack zusammen testest.

Wie Lange Hat es Gedauert, ihn zu Finden?

Start bis Fix: unter einer Stunde.

Das ist schnell. Hier ist was es schnell gemacht hat: die Debugging-Methodologie.

Mit einem AI-Agenten daran zu arbeiten heißt nicht zu fragen "was ist falsch?" und auf eine Antwort zu hoffen. Es heißt dem Agenten gleichzeitig den richtigen Kontext zu geben — die Proxy-Konfiguration, die das Präfix handhabt, die Route-Registrierungs-Dateien in der Table Engine, die Request-Logs die 404 zeigen — und ihn zu bitten, die Diskrepanz zu verfolgen.

Wenn diese Teile zusammen sichtbar sind, kann der Agent über eine Oberfläche pattern-matchen, für die ein menschlicher Ingenieur zwanzig Minuten brauchen würde nur um hinzunavigieren. Der Agent fand den Mismatch zwischen der Proxy-Rewrite-Regel und der Route-Registrierung in der Table Engine in etwa drei Minuten.

Der Bug Hinter Dem Bug

Das Finden des Routing-Bugs legte den nächsten frei.

Der Endpoint antwortete jetzt. Aber die Daten, die er zurückgab, waren im falschen Format.

Die Table Engine spricht intern eine Sprache: Sitznummern, Status-Codes wie occupied, rohe Chip-Counts als simple Integer. Der Front-End-Renderer spricht eine andere: Sitz-Indizes, formatierte Currency-Strings wie $235.50, spezifische Field-Namen, die er per Vertrag von einer Type-Definition erwartet, gegen die er geschrieben wurde.

Niemand schrieb einen Translation-Layer. Die Build Session schrieb den Endpoint und er gab das interne Format zurück. Der Renderer empfing Daten die er nicht erkannte und produzierte stillschweigend nichts.

Das ist die Klasse von Bug, für die man notorisch schwer im Voraus einen Test schreiben kann. Du musst beide Systeme laufen lassen, verbunden, und versuchen lassen miteinander zu sprechen um ihn zu sehen. Kein Unit Test deckt die Lücke zwischen zwei Systemen ab, wenn keines der Systeme für sich genommen einen Bug hat.

Was Das für Die Build-Methodologie Bedeutet

Die Test-Phase bedeutet nicht, dass die Methodologie versagte. Sie bedeutet, dass die Methodologie uns zum Testing brachte.

Jede Software-Plattform hat eine Integrationsschicht, wo die Teile sich in der realen Welt treffen müssen. Spec-driven Entwicklung bringt dich schneller zu dieser Schicht. Sie überspringt sie nicht.

Der nächste Post in dieser Serie behandelt, was passierte, als wir die Korrekturen anwendeten — und der Browser trotzdem dasselbe kaputte Ergebnis zeigte.

Für die Engineering-Methodologie hinter unserem Bauen — die Spec, die Sessions, was der Agent während einer Session tut und was der Architekt tut — gibt es den vollen Bericht auf The Salty Korean.

Stay salty.