ErrorCode now carries two codes for a bad build record, and which side of the record's life each one belongs to is not recoverable from its name.
Both names say "this record is bad" and neither says "…and I was writing it" or "…and I was reading it". The distinction is real and load-bearing: the write-side code means putup failed to produce a record and the build's own output is in question, while the read-side code means putup declined to consume one and will rebuild from scratch. A caller that confuses them announces the wrong thing to the user.
Why it matters now rather than before
Before #383 the read side had one damage code used at one site, so the pairing was easy to hold in your head. #383 made the read side a proper category (three sites, its own announcement arm, its own requirement sentence). Two parallel categories with names that do not distinguish them is the state in which the next person adding a code guesses — and a wrong guess here is silent, because both codes flow to plausible-looking announcement arms.
The announcement filter is now inverted (silence enumerated, everything else announced), so a misfiled code no longer disappears — it gets announced under the wrong sentence instead. Better, still wrong.
Options, no recommendation yet
- Rename to make the side structural:
IndexWriteFailed / IndexDamaged, or IndexCorrupted / IndexUnreadable.
- Or accept the pair as-is and record the split where invariants are documented.
ErrorCode is in-process only — never serialized, never cast, no stability contract — so renaming costs exactly the call sites and nothing else. That is also the argument for doing it rather than documenting around it.
Found during #383; out of scope there.
ErrorCodenow carries two codes for a bad build record, and which side of the record's life each one belongs to is not recoverable from its name.IndexCorrupted— write side only, produced atsrc/index/writer.cpp:169and:177.IndexDamaged— read side only, produced at three sites insrc/index/reader.cppafter Damage that is not a layout failure is still silent: too-small and bad-magic records share a code with the benign version case #383.Both names say "this record is bad" and neither says "…and I was writing it" or "…and I was reading it". The distinction is real and load-bearing: the write-side code means putup failed to produce a record and the build's own output is in question, while the read-side code means putup declined to consume one and will rebuild from scratch. A caller that confuses them announces the wrong thing to the user.
Why it matters now rather than before
Before #383 the read side had one damage code used at one site, so the pairing was easy to hold in your head. #383 made the read side a proper category (three sites, its own announcement arm, its own requirement sentence). Two parallel categories with names that do not distinguish them is the state in which the next person adding a code guesses — and a wrong guess here is silent, because both codes flow to plausible-looking announcement arms.
The announcement filter is now inverted (silence enumerated, everything else announced), so a misfiled code no longer disappears — it gets announced under the wrong sentence instead. Better, still wrong.
Options, no recommendation yet
IndexWriteFailed/IndexDamaged, orIndexCorrupted/IndexUnreadable.ErrorCodeis in-process only — never serialized, never cast, no stability contract — so renaming costs exactly the call sites and nothing else. That is also the argument for doing it rather than documenting around it.Found during #383; out of scope there.