2 Commits

Include renames

Author	SHA1	Message	Date
florian.wilde	76c064bd31	fix(git): haengengebliebene Teil-Abrufe einmal nachschlagen ... 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	2026-09-09 22:46:09 +02:00
florian.wilde	b062eb36a1	fix(sync): Teil-Abrufe verschlucken ihre Fehler nicht mehr ... Behebt florian.wilde/nebula#19 und florian.wilde/nebula#20. getJsonSafe machte aus jedem Fehlschlag eine leere Liste. Damit war ein 403 nicht mehr von "das Repository hat keine Branches" zu unterscheiden: Der Abgleich lief durch, meldete "Snapshot aktualisiert: 0 Branches, 0 Tags", setzte kein syncError - und ueberschrieb dabei den letzten guten Stand mit Nullen. Ein Repository mit 65 Commits sah danach aus wie ein leeres, und die Ursache war nicht zu ermitteln, weil die Auskunft, die sie benannt haette, gerade weggeworfen worden war. Teilabrufe sammelt jetzt je Feld, was schiefging - mit HTTP-Status, denn daran haengt die Ursache: 403 heisst Scopes, 429 Rate-Limit, 408 Zeitueberschreitung, 0 nicht erreicht. Der Fallback bleibt, ein einzelner Fehlschlag darf den ganzen Abgleich nicht abbrechen. Daraus folgt der zweite Teil: persistSnapshot laesst stehen, was nicht geholt werden konnte. Der Snapshot ist ein Zwischenspeicher - ein alter Stand mit sichtbarem Datum ist immer brauchbarer als eine leere Liste, die aussieht wie eine Aussage. Die abgeleiteten Felder gehen mit ihrer Liste: lastCommit* haengt an commits, latestTag an tags UND releases, sonst waeren sie in sich widerspruechlich. Bewusst kein Fehlschlag: syncError bleibt leer und der Zaehler fuers Zurueckhalten steigt nicht. Der Rest des Standes ist frisch, und ein Repository deswegen stundenlang auszusetzen waere die falsche Antwort. GIT_API_TIMEOUT_MS wird geprueft. Number("") ist 0 und Number("abc") ist NaN; setTimeout loest bei beidem sofort aus, und dann bricht jeder Aufruf ab, bevor er beginnt. Eine verrutschte Zeile in der .env legte damit den ganzen Abgleich still - lautlos, versteht sich. NACHGEWIESEN, NICHT BEHAUPTET Gegen einen nachgebauten Gitea-Server, der genau den beobachteten Fall erzeugt - Basis-Aufruf antwortet, Teillisten geben 403 - und eine Wegwerf-Datenbank: gesund branchCount=2 tagCount=3 commits=2 releases=1 missing={} kaputt branchCount=2 tagCount=3 commits=2 releases=1 missing={8 Felder mit HTTP 403}, completeAt unveraendert wieder gut missing={} , completeAt fortgeschrieben Nichts verloren, die Luecke steht in der Meldung und am Repository, und nach dem naechsten gesunden Durchlauf raeumt sie sich von selbst weg. axe-core 0 Verstoesse auf 1280 und 375 px, kein seitlicher Ueberlauf. Der eigentliche Grund der Ausfaelle auf der Instanz ist damit noch nicht gefunden - aber ab jetzt steht er auf der Projektseite. Refs #19 Refs #20	2026-09-01 18:09:01 +02:00