From 0c1786ba8c1704f0b3822a7fb2eba9a46011c29f Mon Sep 17 00:00:00 2001 From: Administrator Date: Thu, 11 Jun 2026 13:44:22 +0200 Subject: [PATCH] docs(lessons): byse suspect-reject Erkenntnisse + GitHub-Mirror-Prozedur (v3.3.66) --- tasks/lessons.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/tasks/lessons.md b/tasks/lessons.md index 2c8397f..b87bf2b 100644 --- a/tasks/lessons.md +++ b/tasks/lessons.md @@ -62,3 +62,21 @@ - file/list → 90.548 Dateien; Uploads landen server-seitig INTERMITTIEREND (viele Burn-Notice-Folgen genau im "Fehler"-Zeitfenster vorhanden). Das leere Formular ist also nicht "immer kaputt", sondern manchmal — der Web-Form-Registrierungs-Callback (fs-public.intconnect.net) timeoutet sporadisch. **Konsequenz:** API-Weg (result[0].filecode inline) umgeht den failenden Callback → richtiger Fix. file/list-Recovery ist NICHT tote Last (Dateien erscheinen ja) — aber bei 90k-Accounts MUSS man sort=created&order=desc erzwingen, sonst ist die frische Datei nicht auf Seite 1. **Regel:** Bei "geht manchmal/manchmal nicht" + Hoster mit offizieller API: erst per read-only API-Call (account/info, file/list) gegen den ECHTEN Account verifizieren statt am Client weiterzuraten. Das beendet Spekulations-Schleifen. + +## 2026-06-11 — Rotation erreichte Account 4 nie (v3.3.66) +- **Hoster-Fehlertexte lügen tier-abhängig:** byse "Not video file format" war für valide + MKVs >2,7GB ein Account-Größen-Limit (Beweis: sauberer Size-Split 1158 OK ≤2,62GB vs. + 6 rejected ≥2,81GB auf demselben Account). Eine "file rejected → Rotation sinnlos"- + Klassifizierung darf nie nur auf dem Servertext beruhen, wenn die eigene File-Probe + das Gegenteil beweist (probe sagt matroska → Verdikt suspekt → andere Accounts testen). +- **Optimierungen gegen dokumentierte Rescue-Pfade diffen:** 1d116ac ("skip 30s poll on + explicit reject") hat den Poll exakt für den Fall getötet, dessen Kommentar 5 Zeilen + darüber stand. Vor jedem Guard um einen bestehenden Rettungspfad: dessen Kommentar/Tests + lesen, sonst zementiert der neue Test die Regression (Test behauptete das Skip-Verhalten). +- **Jeder Retry-Pfad braucht dieselbe Fehler-Klassifizierung + dasselbe Logging wie der + Hauptpfad:** Der Rotations-Inner-Loop hatte weder upload-failure-Logs (Account 2 starb + unsichtbar — Diagnose unmöglich) noch fileRejected-Fast-Breaks (4× 2,7GB-Re-Upload, dann + Blacklist eines gesunden Accounts). +- **GitHub-Mirror-Falle:** Mirror hat separate bereinigte Historie (ohne electron-config.json). + `gh release create` pusht Tags aus der LOKALEN Historie → Credentials-Leak. Prozedur: + Cherry-Pick-Worktree auf github/master, Tag auf Mirror-Commit. (Memory: feedback_github_mirror_separate_history)