Warum die Messung eines einzigen Lesers zur Löschung von Dateien führte, die für Tests benötigt wurden

Am 31. Oktober 2026 verschob ein Entwickler, der an einem Content-Sammlungssystem arbeitete, 34.557 HTML-Dateien in die Quarantäne, nachdem er festgestellt hatte, dass ein bestimmter Reader-Prozess nie auf sie zugegriffen hatte. Die unmittelbare Sammelrunde wurde erfolgreich abgeschlossen, aber ein anschließender Vergleich mit einer versiegelten Test-Baseline offenbarte 310 neue Fehler. Die Dateien wurden am selben Tag wiederhergestellt, was einen dauerhaften Datenverlust vermied, doch der Vorfall deckte erhebliche Lücken darin auf, wie das System die Dateinutzung über verschiedene Komponenten hinweg nachverfolgte.

Was passiert ist

Das Berichtsverzeichnis des Systems war auf 132,8 GiB angewachsen, ohne dass Alarme ausgelöst wurden, da Jobs, die alle 15 Minuten liefen, neue Ordner ohne Bereinigung erstellten. Ein erster referenzbasierter Bereinigungsdurchgang reduzierte die Größe auf 115,1 GiB, indem nicht referenzierte Einheiten entfernt und eine SQLite-Datenbank komprimiert wurden, aber der Großteil der verbleibenden Daten wurde weiterhin vom Sammlungszustand referenziert. Um den verbleibenden Umfang anzugehen, maß der Entwickler, welche Dateien ein Validator für den Sammlungszustand während eines Laufs von 16:50 bis 17:40 KST öffnete. Von 46.643 gesammelten HTML-Dateien mit einer Gesamtgröße von 52,4 GiB öffnete der Validator nur 1.920 Dateien. Die verbleibenden 34.557 Dateien, größtenteils Historieneinträge für erneut abgerufene Videos, wurden als unnötig eingestuft und in die Quarantäne verschoben.

Als jedoch die vollständige Testsuite ausgeführt wurde, produzierte sie 310 Fehler über die bestehende Baseline hinaus. Diese Fehler umfassten ValueError-Ausnahmen bezüglich nicht verfügbarer YouTube-Seitenkörper und FileNotFoundError-Probleme wegen fehlender HTML-Dateien. Die Fehler traten auf, weil andere Prozesse, wie Publish-Replay und Backlog-Judging, weiterhin Zugriff auf diese Roh-Capture-Körper benötigten. Der Entwickler hatte fälschlicherweise angenommen, dass, weil ein Reader die Dateien nicht öffnete, kein Teil des Systems sie benötigte. Die Quarantänestrategie ermöglichte eine schnelle Wiederherstellung durch Umbenennen der Dateien zurück, wodurch das System in einen fehlerfreien Zustand mit null fehlenden Dateien versetzt wurde.

Wichtige Details

• Anfänglicher Messfehler: Der Entwickler maß den Dateizugriff nur für einen Reader (den Validator für den Sammlungszustand) und ignorierte andere Komponenten wie Replays der Veröffentlichungs-Warteschlange.
• Umfang der Auswirkung: 34.557 HTML-Dateien mit einer Gesamtgröße von 37,8 GiB wurden aufgrund unvollständiger Daten in die Quarantäne verschoben.
• Fehlschlag der Testsuite: Die Ausführung der vollständigen Testsuite ergab 310 neue Fehler, hauptsächlich aufgrund fehlender roher HTML-Dateien, die für Replay und Provenance-Tracking benötigt wurden.
• Wiederherstellungsmethode: Dateien wurden verschoben statt gelöscht, was eine Wiederherstellung per Umbenennung ermöglichte, ohne dass ein erneutes Crawling externer Quellen erforderlich war.
• Fallen beim Recorder: Der Datei-Zugriffs-Recorder übersah Lesevorgänge aufgrund von Pfad-Mismatches bei relativen Pfaden in Python 3.13.0 Audit-Hooks und verlor Aufzeichnungen, wenn der Haupt-Pytest-Prozess über os._exit(1) beendet wurde.
• Aktueller Status: Stand 4. November 2026 ist das Speicher-Gate rot, da drei von vier nächtlichen Läufen im Zustand restored endeten, was die Ausführung des finalen Löschschritts verhinderte.

Hintergrund

In komplexen Softwaresystemen, insbesondere solchen, die große Datenmengen wie Content-Pipelines verarbeiten, ist es entscheidend für die Wartung zu verstehen, welche Dateien aktiv genutzt werden. Ein „Reader“ bezieht sich in diesem Kontext auf jeden Prozess oder jede Komponente, die Datendateien öffnet und verarbeitet. Entwickler verwenden häufig Monitoring-Tools oder Audit-Hooks, um den Dateizugriff nachzuverfolgen und so einen „Read Set“ der Dateien zu erstellen, die während einer bestimmten Operation geöffnet wurden. Das Komplement dieses Sets – Dateien, die nicht geöffnet wurden – wird manchmal als sicher für die Löschung angesehen. Diese Annahme ist jedoch gefährlich, wenn das Monitoring nicht alle möglichen Reader abdeckt, einschließlich Hintergrundjobs, Testsuites oder seltener Edge-Case-Handler.

Quarantäne ist eine Sicherheitspraxis, bei der Dateien an einen separaten Ort verschoben werden, anstatt sie dauerhaft zu löschen. Dies ermöglicht es Teams, zu überprüfen, ob das System ohne die Daten korrekt funktioniert, bevor man sich zu einer irreversiblen Entfernung verpflichtet. Wenn Probleme auftreten, können die Dateien schnell zurückverschoben werden. Dieser Ansatz steht im Gegensatz zum direkten Löschen, das bei einer falschen Entscheidung teure und zeitaufwändige Neubeschaffungen von Daten aus externen Quellen erfordern würde.

Warum es wichtig ist

Für Teams, die Self-Hosted-Software betreiben oder interne Datenpipelines verwalten, illustriert dieser Vorfall die versteckte Komplexität des Datenlebenszyklusmanagements. Es ist leicht anzunehmen, dass statische Analyse oder eingeschränktes Runtime-Monitoring ein vollständiges Bild der Datenabhängigkeiten liefert. In Realität haben Systeme oft latente Abhängigkeiten, bei denen Daten nur während spezifischer Ereignisse zugegriffen werden, wie etwa bei Fehlerwiederherstellung, historischer Nachverarbeitung oder umfassendem Testing. Das Löschen von Daten basierend auf teilweiser Sichtbarkeit kann zu subtilen Fehlern führen, die schwer zu diagnostizieren und teuer in der Behebung sind.

Die Abhängigkeit von einer einzigen Metrik – dem Read Set eines Validators – erzeugte ein falsches Gefühl der Sicherheit. Die Tatsache, dass die unmittelbare Sammelrunde nach der Quarantäne bestand, täuschte den Entwickler darüber hinweg, dass die Änderung sicher war. Erst die breitere Testsuite, die verschiedene operative Szenarien einschließlich Replays und historischer Joins simuliert, offenbarte die fehlenden Abhängigkeiten. Dies unterstreicht die Bedeutung der Verwendung umfassender Testsuiten als Validierungstool für Infrastrukturänderungen, nicht nur für Code-Logik.

Darüber hinaus zeigen die technischen Fallstricke, die mit dem Datei-Zugriffs-Recorder auftraten, dass sogar Monitoring-Tools blinde Flecken haben können. Probleme wie relative Pfadauflösung in Audit-Hooks oder Prozessbeendigungs-Verhalten können zu einer Unterzählung der Dateizugriffe führen. Bei Datenbereinigungsoperationen ist eine Unterzählung besonders gefährlich, da sie direkt das Risiko erhöht, aktive Daten zu löschen. Teams müssen ihre Monitoring-Tools gegen bekannte Baselines validieren, um sicherzustellen, dass sie alle relevanten Aktivitäten erfassen.

Was Sie tun können

• Verschieben vor Löschen: Verschieben Sie Kandidatendateien immer in ein Quarantäne-Verzeichnis mit einem festen Timer vor der dauerhaften Löschung, um sicherzustellen, dass Fehler günstig rückgängig gemacht werden können.
• Alle Reader messen: Berechnen Sie Löschkandidaten gegen jede Komponente, die auf die Daten zugreifen könnte, einschließlich Hintergrundjobs, Replay-Mechanismen und der vollständigen Testsuite.
• Monitoring-Tools validieren: Testen Sie Ihre Datei-Zugriffs-Recorder gegen Reader mit bekanntem Verhalten, um sicherzustellen, dass sie keine Lesevorgänge aufgrund von Pfadauflösungs- oder Prozessbeendigungsproblemen übersehen.
• Vollständige Testsuiten ausführen: Vergleichen Sie nach jeder Datenbewegung die Ergebnisse der vollständigen Testsuite mit einer versiegelten Baseline, um latente Abhängigkeiten zu erkennen, die unmittelbare Smoke-Tests möglicherweise übersehen.
• Tripwires implementieren: Richten Sie Jobs ein, die Logs auf Versuche überwachen, fehlende Dateien zu lesen, damit Sie versehentlich gelöschte Daten erkennen und wiederherstellen können, bevor sie weitreichende Fehler verursachen.
• Quarantäne aus Budgets ausschließen: Schließen Sie bei der Berechnung der Speichernutzung quarantänisierte Bytes aus dem Hauptbudget aus, um Verwirrung über die tatsächliche Größe aktiver Daten zu vermeiden, während sie für die Wiederherstellung verfügbar bleiben.