[johnf]

Summary

schema.org contentSize is text (its example is "25 KB"). The structural indexer coerced it with +, so "14384 bytes" became NaN and prisma.file.create failed for every file in the crate. Prisma's error reports "Argument entity is missing", which is misleading. The entity rows were saved; only the file rows were lost.

 file size
-  +(contentSize ?? size in OCFL inventory)      # NaN for "14384 bytes"
+  size in OCFL inventory, if the file is there
+  else leading integer of contentSize           # "14384 bytes" → 14384
+  else -1

The inventory now wins over contentSize, because it is the real size of the stored file. contentSize with other units is taken at face value: "25 KB" → 25. That only applies to files missing from OCFL, where the size is a best guess anyway.

Evidence

On the dev server, crate arcp://name,hdl10.25949~24769173.v1 lost all 1069 file rows.

New tests in src/indexer/structural.test.ts run StructuralIndexer.index against a fake CrateObject and the test database:

• Before: 3 failed
  • file in inventory (500), contentSize: "14384 bytes" → no file row
  • file missing, contentSize: "14384 bytes" → no file row
  • file missing, contentSize: "unknown" → no file row (expected -1)
• After: all pass: 500, 14384 (and 163840 for a numeric contentSize), -1. Full suite: 166 passed.

Merge Danger

Door: two-way

Only the stored size changes. Re-running pnpm index rebuilds the rows.

Blast Radius: small

File sizes shown by the API can change where a crate's numeric contentSize disagreed with the file in OCFL. The search indexer doesn't read contentSize.