429 wird wiederholt, statt den ganzen Lauf zu verlieren
Von zehn Voll-Laeufen im Berichts-Verzeichnis mussten ZWEI (20 %) wegen HTTP 429
verworfen werden — Fehlerquoten 30,7 % und 12,9 %, waehrend die uebrigen acht bei
0,0 % lagen. Die Ausfaelle sind ganze Laeufe, kein verteiltes Rauschen.
UND SIE KOSTEN MEHR ALS EINEN LAUF: `rot-31` meldet den ZUWACHS und braucht zwei
aufeinanderfolgende verwertbare Laeufe. Faellt einer aus, vergleicht der naechste
gegen einen aelteren und wiederholt einen bekannten Befund — ein echter Neuzugang
in genau diesem Fenster bleibt unbemerkt.
Wiederholung sitzt in `bbGet`, dem einzigen Netz-Engpass: hoechstens 3 Versuche,
wachsende Wartezeit 1s/4s, und die Angabe des Servers gewinnt ueber die eigene Zahl.
🔴 NUR bei 429. Ein 404 (Repositorium ohne Ketten) ist kein Wiederholungs-Fall und
loest keine Wartezeit aus; ein 401 ebenso wenig — dreimal falsch anmelden macht die
Anmeldung nicht richtig.
🔴 `Retry-After` traegt ZWEI Formen — eine Sekundenzahl ODER ein HTTP-Datum. Wer nur
die Zahl liest, bekommt beim Datum ein NaN und wartet gar nicht, laeuft also sofort
in die naechste Drosselung.
🔴 `errors` wird NICHT unterdrueckt: haelt die Drosselung an, wirft der letzte Versuch
wie bisher. Sonst verwirft der Qualitaets-Filter des Fachs nichts mehr und jeder
gedrosselte Lauf gilt als vollstaendig — die dokumentierte "falsche Null".
Die Zusammenfassung nennt die Wiederholungen NEBEN den Fehlern (Konsole + JSON-Bericht) —
sonst ist ein sauberer Lauf von einem sauber gewarteten nicht zu unterscheiden.
`bbGet` ist exportiert mit einspeisbarem fetch/sleep: nur die reinen Helfer zu pruefen
belegt, dass der PLAN stimmt, nicht dass die Schleife ihn befolgt. Die Abnahme verlangt
ausdruecklich einen Lauf, in dem ein 429 AUFTRAT und aufgefangen wurde.
13 Proben. Drei Flip-Proben gefahren: keine Wiederholung -> 5 rot · Retry-After
ignoriert -> 2 rot · 429 unterdrueckt statt geworfen -> 2 rot.
verworfen werden — Fehlerquoten 30,7 % und 12,9 %, waehrend die uebrigen acht bei
0,0 % lagen. Die Ausfaelle sind ganze Laeufe, kein verteiltes Rauschen.
UND SIE KOSTEN MEHR ALS EINEN LAUF: `rot-31` meldet den ZUWACHS und braucht zwei
aufeinanderfolgende verwertbare Laeufe. Faellt einer aus, vergleicht der naechste
gegen einen aelteren und wiederholt einen bekannten Befund — ein echter Neuzugang
in genau diesem Fenster bleibt unbemerkt.
Wiederholung sitzt in `bbGet`, dem einzigen Netz-Engpass: hoechstens 3 Versuche,
wachsende Wartezeit 1s/4s, und die Angabe des Servers gewinnt ueber die eigene Zahl.
🔴 NUR bei 429. Ein 404 (Repositorium ohne Ketten) ist kein Wiederholungs-Fall und
loest keine Wartezeit aus; ein 401 ebenso wenig — dreimal falsch anmelden macht die
Anmeldung nicht richtig.
🔴 `Retry-After` traegt ZWEI Formen — eine Sekundenzahl ODER ein HTTP-Datum. Wer nur
die Zahl liest, bekommt beim Datum ein NaN und wartet gar nicht, laeuft also sofort
in die naechste Drosselung.
🔴 `errors` wird NICHT unterdrueckt: haelt die Drosselung an, wirft der letzte Versuch
wie bisher. Sonst verwirft der Qualitaets-Filter des Fachs nichts mehr und jeder
gedrosselte Lauf gilt als vollstaendig — die dokumentierte "falsche Null".
Die Zusammenfassung nennt die Wiederholungen NEBEN den Fehlern (Konsole + JSON-Bericht) —
sonst ist ein sauberer Lauf von einem sauber gewarteten nicht zu unterscheiden.
`bbGet` ist exportiert mit einspeisbarem fetch/sleep: nur die reinen Helfer zu pruefen
belegt, dass der PLAN stimmt, nicht dass die Schleife ihn befolgt. Die Abnahme verlangt
ausdruecklich einen Lauf, in dem ein 429 AUFTRAT und aufgefangen wurde.
13 Proben. Drei Flip-Proben gefahren: keine Wiederholung -> 5 rot · Retry-After
ignoriert -> 2 rot · 429 unterdrueckt statt geworfen -> 2 rot.