compactor.js · Abweichung 1 von 4

Die Strangsuche läuft rückwärts

Jeder Eintrag zeigt mit ref auf den älteren Eintrag, auf den er antwortet — neu zeigt auf alt. findClosedStrand() folgt genau dieser Richtung: von einem Eintrag aus zu seinem ref-Ziel und von dort weiter zurück.

Nur beantwortet das keine der Fragen, die die Regeln 2 und 3 stellen. Ob ein Strang geschlossen ist, hängt nicht davon ab, worauf ein Eintrag selbst zeigt, sondern davon, ob etwas Neueres noch auf ihn zeigt. Das ist die umgekehrte Richtung — und die prüft der Code nirgends.

Zwei Stränge, zwei Fragen

Strang

Prüfung

Code-Pfad, Strang e01–e03: Der Rückwärtsgang von e03 über e02 nach e01 zeigt nur, worauf e03 selbst antwortet — die eigene Vorgeschichte. Ob e04, e05, e06 oder e07 auf e03 zeigen, kommt dabei nie zur Sprache.

ref zeigt immer von neu nach alt (dünne Pfeile unten). Links wählst du den Strang, rechts die Prüfung: Code-Pfad spielt ab, was findClosedStrand() tatsächlich tut — den eigenen ref rückwärts verfolgen. Eigentliche Frage prüft stattdessen jeden neueren Eintrag: Zeigt er hierher?

Was das für Regel 2 und 3 heißt

Für die letzten zwei Sitzungen sollen zusammenhängende Stränge zu einem Block zusammengezogen werden, Zeitstempel bleiben erhalten — dafür muss der Strang geschlossen sein: Niemand Neueres baut noch auf ihm auf. Weil findClosedStrand() die falsche Richtung prüft, findet die Funktion nie einen geschlossenen Strang. Die Regeln 2 und 3 feuern deshalb nie.

Offen für das Gespräch mit Richard (siehe checkliste-richard.md, Abschnitt 2):

Zeigt ref tatsächlich immer neu → alt? Dann ist es ein Zeilen-Fix: findClosedStrand() müsste eingehende statt ausgehende Verweise prüfen.
War die Rückwärtsrichtung Absicht — verfolgt der Code etwas anderes als geplant?
Wer gleicht an, und braucht runCompaction vorher eine Sicherung?

Grundlage: der schreibfreie Trockenlauf node tools/dry-compaction.mjs, Bericht in tools/dry-compaction-report.md. Änderung erst nach Rücksprache mit Richard, vor der finalen Fertigstellung.