Fix #23: Haengengebliebene Teil-Abrufe einmal nachschlagen #25

2026-09-09T20:46:54Z

florian.wilde commented

2026-09-09 20:46:54 +00:00

Beobachtet an der laufenden Instanz: zwei von acht Teil-Abrufen liefen in eine Zeitüberschreitung nach 15 s, während dieselben Aufrufe von außen einzeln in 80 ms antworteten. Nicht die Endpunkte sind langsam — die Achterrunde erwürgt sich gelegentlich selbst.

Die Maßnahme folgt aus dem Befund

Was hängen bleibt, bekommt einen zweiten Versuch — und der läuft nicht wieder im Schwung mit. Die Nachschläge hängen an einer Kette und gehen nacheinander hinaus.

Gelöst in Teilabrufe statt hinter dem Promise.all: so bleiben die Aufrufstellen in den drei Clients unberührt, hol() liefert weiterhin den endgültigen Wert. Hinter dem Promise.all hätte jeder Client acht Variablen neu zuweisen müssen.

Zwei Grenzen, beide absichtlich

Nur bei 408 und 0 — Zeitüberschreitung und eine Verbindung, die gar nicht zustande kam. Ein 403 wird durch Wiederholen nicht besser, ein 429 durch sofortiges Wiederholen schlimmer, ein 404 bleibt ein 404.

Höchstens zweimal je Abgleich. Acht Zeitüberschreitungen zu je 15 Sekunden wären zwei Minuten, in denen „Jetzt synchronisieren" wie ein Absturz aussieht. Wer weg ist, soll schnell als weg erkannt werden.

Klappt auch der zweite Versuch nicht, steht das am Repository — mit dem Vermerk „(auch im zweiten Versuch)", damit erkennbar bleibt, dass es kein Zufall war.

Was ich nicht gemacht habe

Die acht Aufrufe entzerren. Das wäre eine Vermutung über die Ursache, kein Schluss aus dem Gemessenen. Bleibt das Problem, sagt der Vermerk genau das — und dann ist die Entzerrung dran, mit Begründung.

Am Rande behoben

Den beiden afterEach-Blöcken in http.test.ts fehlte restoreAllMocks. Die Spies zählten über Tests hinweg weiter; aufgefallen, weil die neuen Prüfungen an Aufrufzahlen hängen und statt 2 gleich 10 sahen. Das war ein Fehler in den Tests, den ich beim Hinzufügen der Teilabrufe-Tests selbst hineingetragen hatte.

Geprüft

tsc sauber · 295 Unit-Tests (6 neue) · npm run build durch
Die neuen Tests decken ab: geglückter Nachschlag, gescheiterter Nachschlag mit Vermerk, kein Nachschlag bei 403, keiner bei 429, der Deckel von zwei, und dass eine gescheiterte Kette die folgenden Nachschläge nicht mitreißt
Gegengeprobt: mit abgeschaltetem Nachschlag fallen vier der sechs — die beiden, die das Ausbleiben prüfen, bleiben grün

Unabhängig von #22, das parallel als #24 offen liegt; beide fassen verschiedene Dateien an.

Closes #23

Beobachtet an der laufenden Instanz: zwei von acht Teil-Abrufen liefen in eine Zeitüberschreitung nach 15 s, während dieselben Aufrufe von außen einzeln in 80 ms antworteten. Nicht die Endpunkte sind langsam — die Achterrunde erwürgt sich gelegentlich selbst. ## Die Maßnahme folgt aus dem Befund Was hängen bleibt, bekommt einen zweiten Versuch — und der läuft **nicht** wieder im Schwung mit. Die Nachschläge hängen an einer Kette und gehen nacheinander hinaus. Gelöst in `Teilabrufe` statt hinter dem `Promise.all`: so bleiben die Aufrufstellen in den drei Clients unberührt, `hol()` liefert weiterhin den endgültigen Wert. Hinter dem `Promise.all` hätte jeder Client acht Variablen neu zuweisen müssen. ## Zwei Grenzen, beide absichtlich **Nur bei `408` und `0`** — Zeitüberschreitung und eine Verbindung, die gar nicht zustande kam. Ein `403` wird durch Wiederholen nicht besser, ein `429` durch sofortiges Wiederholen schlimmer, ein `404` bleibt ein `404`. **Höchstens zweimal je Abgleich.** Acht Zeitüberschreitungen zu je 15 Sekunden wären zwei Minuten, in denen „Jetzt synchronisieren" wie ein Absturz aussieht. Wer weg ist, soll schnell als weg erkannt werden. Klappt auch der zweite Versuch nicht, steht das am Repository — mit dem Vermerk „(auch im zweiten Versuch)", damit erkennbar bleibt, dass es kein Zufall war. ## Was ich nicht gemacht habe Die acht Aufrufe entzerren. Das wäre eine Vermutung über die Ursache, kein Schluss aus dem Gemessenen. Bleibt das Problem, sagt der Vermerk genau das — und dann ist die Entzerrung dran, mit Begründung. ## Am Rande behoben Den beiden `afterEach`-Blöcken in `http.test.ts` fehlte `restoreAllMocks`. Die Spies zählten über Tests hinweg weiter; aufgefallen, weil die neuen Prüfungen an Aufrufzahlen hängen und statt 2 gleich 10 sahen. Das war ein Fehler in den Tests, den ich beim Hinzufügen der `Teilabrufe`-Tests selbst hineingetragen hatte. ## Geprüft - `tsc` sauber · **295 Unit-Tests** (6 neue) · `npm run build` durch - Die neuen Tests decken ab: geglückter Nachschlag, gescheiterter Nachschlag mit Vermerk, kein Nachschlag bei `403`, keiner bei `429`, der Deckel von zwei, und dass eine gescheiterte Kette die folgenden Nachschläge nicht mitreißt - **Gegengeprobt:** mit abgeschaltetem Nachschlag fallen vier der sechs — die beiden, die das *Ausbleiben* prüfen, bleiben grün Unabhängig von #22, das parallel als #24 offen liegt; beide fassen verschiedene Dateien an. Closes #23

florian.wilde added 1 commit 2026-09-09 20:46:54 +00:00

fix(git): haengengebliebene Teil-Abrufe einmal nachschlagen

CI / pruefen (pull_request) Canceled after 0s

Details

76c064bd31

Behebt florian.wilde/nebula#23.

Beobachtet an der laufenden Instanz: zwei von acht Teil-Abrufen liefen in
eine Zeitueberschreitung nach 15 s, waehrend dieselben Aufrufe von aussen
einzeln in 80 ms antworteten. Nicht die Endpunkte sind langsam - die
Achterrunde erwuergt sich gelegentlich selbst.

Daraus folgt die Maßnahme, und zwar genau diese: was haengen bleibt,
bekommt einen zweiten Versuch, und der laeuft NICHT wieder im Schwung
mit. Die Nachschlaege haengen an einer Kette und gehen nacheinander
hinaus.

Die Aufrufstellen in den drei Clients bleiben unberuehrt - hol() liefert
weiterhin den endgueltigen Wert. Das war der Grund, es in Teilabrufe zu
loesen statt hinter dem Promise.all: dort haette jeder Client acht
Variablen neu zuweisen muessen.

ZWEI GRENZEN, BEIDE ABSICHTLICH

Nachgeschlagen wird nur bei 408 und bei 0 - Zeitueberschreitung und eine
Verbindung, die gar nicht zustande kam. Ein 403 wird durch Wiederholen
nicht besser, ein 429 durch sofortiges Wiederholen schlimmer, ein 404
bleibt ein 404.

Und hoechstens zweimal je Abgleich. Acht Zeitueberschreitungen zu je 15
Sekunden waeren zwei Minuten, in denen "Jetzt synchronisieren" wie ein
Absturz aussieht. Wer weg ist, soll schnell als weg erkannt werden.

Klappt auch der zweite Versuch nicht, steht das am Repository - mit dem
Vermerk "(auch im zweiten Versuch)", damit erkennbar bleibt, dass es kein
Zufall war.

NICHT GEMACHT: die acht Aufrufe entzerren. Das waere eine Vermutung ueber
die Ursache. Bleibt das Problem, sagt der Vermerk genau das, und dann ist
die Entzerrung dran.

AM RANDE BEHOBEN

Den beiden afterEach-Bloecken in http.test.ts fehlte restoreAllMocks.
Die Spies zaehlten ueber Tests hinweg weiter; aufgefallen, weil die neuen
Pruefungen an Aufrufzahlen haengen und statt 2 gleich 10 sahen.

Gegengeprobt: mit abgeschaltetem Nachschlag fallen vier der sechs neuen
Tests - die beiden, die das Ausbleiben pruefen, bleiben gruen.

Refs #23

florian.wilde referenced this pull request

2026-09-09 20:47:15 +00:00

Sporadische Zeitueberschreitungen beim Abgleich #23

florian.wilde merged commit e1b71f5fb6 into main

2026-09-09 22:12:21 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: florian.wilde/nebula#25