daniel/reasampler
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix: classify future-version ledgers with changed record shape correctly, not as corrupt

Browse Source 
Version-check now runs on the parseLedger failure path too, so a v3 blob whose record shape actually changed reports FutureVersion instead of Unreadable, avoiding the corrupt-blob "clear it" advice. Also closes the six minor findings.
This commit is contained in:
Daniel Harvey
2026-07-30 20:25:46 -04:00
parent 45b87dc2ff
commit 6287534454
6 changed files with 67 additions and 22 deletions
Download Patch File Download Diff File Expand all files Collapse all files
tests/test_origin_ledger.cpp
+16 -4
View File
@@ -258,6 +258,17 @@ static void testFutureVersionIsNeitherLoadedNorMalformed() {
CHECK(loadLedger("{\"v\":2,\"records\":[]}").status == LedgerStatus::Loaded);
CHECK(loadLedger("{\"v\":1,\"owned\":[\"a.wav\"]}").status == LedgerStatus::Loaded);
CHECK(loadLedger("{\"v\":-1,\"records\":[]}").status == LedgerStatus::Unreadable);
// A future version whose record shape actually changed — not just grew — fails
// parseRecord under these v2 rules ("kind" retyped from int to string). That must
// still classify as FutureVersion, not Unreadable: this is the exact "changed
// record shape" case the version ladder comment says v3 means, and Unreadable
// would steer the operator into clearing a newer build's ledger.
CHECK(loadLedger("{\"v\":3,\"records\":[{\"path\":\"a.wav\",\"kind\":\"loud\"}]}")
.status == LedgerStatus::FutureVersion);
// Same, with the array itself retyped to an object.
CHECK(loadLedger("{\"v\":3,\"records\":{\"path\":\"a.wav\"}}").status ==
LedgerStatus::FutureVersion);
}
// A hand-edited or corrupt blob cannot smuggle an absolute or duplicate path past
@@ -315,8 +326,11 @@ static void testLegacyPathOnlyManifestLiftsIn() {
// A recapture regenerates the audio behind ONE bank id under a NEW file name
// (makeUniqueTag guarantees it), so the ledger legitimately ends up holding two
// records with the same sampleId and different paths. The original's lineage survives
// untouched — the Sample was rewritten in place, the birth record was not.
// records with the same sampleId and different paths. This proves that shape and
// that take-1's record is untouched by take-2's insert (record() never overwrites —
// see testLineageIsNeverBackfilled for the same-path case). It does NOT exercise the
// ledger-wins-over-the-mutable-Sample claim: nothing here reads Sample.provenance, and
// no production code reads OriginRecord.parentSampleId today.
static void testRecaptureAddsSecondRecordUnderTheSameSampleId() {
OriginLedger l;
l.record(rec("bank/take-1.wav", OriginKind::Capture, "S-1", "S-parent"));
@@ -326,8 +340,6 @@ static void testRecaptureAddsSecondRecordUnderTheSameSampleId() {
CHECK(l.size() == 2);
CHECK(l.find("bank/take-1.wav")->sampleId == "S-1");
CHECK(l.find("bank/take-2.wav")->sampleId == "S-1");
// The ledger, not the (mutable) Sample, is authoritative for lineage: the
// recapture's differing parent did not rewrite the original's.
CHECK(l.find("bank/take-1.wav")->parentSampleId == "S-parent");
CHECK(l.find("bank/take-1.wav")->kind == OriginKind::Capture);
// Both stay owned, so the superseded file is reclaimable rather than foreign.