[perfloop]

Startup recovery now preserves pending raw-file data when a metadata point read or file stat fails for an operational reason. It returns the validation error instead of treating an unproven check as grounds for deletion. Confirmed missing metadata, ENOENT, and size-mismatch cleanup remain unchanged.

Recovery aggregates validation errors across batches while allowing unrelated, confirmed cleanup to finish. If recovery fails while NewStorageWithConfig is starting up, it closes the segment manager and metadata database before returning, so a caller can retry in the same process. No public API or on-disk schema changes.

TestRecoveryValidationFailureIsNonDestructive injects metadata-read and non-ENOENT stat errors separately, checks the returned error and preserved metadata, compaction row, and file bytes, then clears the fault and verifies Storage.Get. Its 101-entry case also checks both errors across the 100-result batch boundary. Cleanup controls cover missing metadata, ENOENT, and size mismatch; other tests verify unrelated confirmed cleanup and that failed startup releases the database lock. The fault-reach checks now fail if an injected path is not exercised instead of skipping the assertions.

The focused and full storage tests, race suite, selected cache-warming workflow integration test, all-target build, lint, and license checks passed.

The same assertion was violated on comparison revision eaaa3f8e92d3b6d9a2c36406a185c87723a32f23 and satisfied on the final source.

Recorded proof ran with retained support that is not included in this pull request.

An earlier unfiltered integration run timed out at tests/integration: TestIntegration_Objects; the selected cache-warming workflow case passed. Full repository CI remains pending. Production frequency of these injected failure types is unmeasured.

---

Generated by Perfloop. Measurements and checks. Reproduce this comparison (tenant access required).

---

Note

Medium Risk
Changes startup recovery deletion semantics and storage init teardown on failure; incorrect inconclusive handling could leave stale compaction rows, but the shift reduces risk of data loss on transient I/O errors.

Overview
Startup recovery no longer deletes pending raw-file metadata, compaction rows, or on-disk bytes when validation cannot be proven—metadata point-read I/O failures and non-ENOENT stat errors are treated as inconclusive, left untouched, and surfaced as aggregated errors instead of being classified as corrupted/missing.

Confirmed cleanup behavior is unchanged for orphaned metadata, genuine missing files, and size mismatches. Unrelated entries that validate conclusively still get cleaned up in the same run. If recovery fails during NewStorageWithConfig, the constructor now closes the segment manager and metadata DB so the process can retry without holding the RocksDB lock.

Injectable getMetadata / statFile hooks and external tests cover non-destructive failure paths, cross-batch error joining, constructor retry, and cleanup controls.

^{Reviewed by Cursor Bugbot for commit f60f7c8. Bugbot is set up for automated code reviews on this repo. Configure here.}

[greptile-apps]

Confidence Score: 5/5

[High risk] Changes file recovery validation and error handling on startup.

The PR appears safe to merge based on the reviewed changes.

Summary

The PR preserves pending raw-file data when recovery validation fails, returns validation errors across batches, and releases startup resources after a recovery error.

• The changes since the previous review make unreached injected faults fail the regression tests rather than skip them.
• The previous finding is fixed; its thread is resolved.

_{Reviews (2) · Last reviewed commit: "fix: preserve entries when recovery vali..."}