astrid-runtime/astrid · error
invalid interior Astrid volume record length at
Error message
invalid interior Astrid volume record length at {offset} What it means
When a record's total_len exceeds the remaining bytes in the region, the recovery code checks whether another physically valid record starts right after this one. If such a valid record exists, the oversized length is treated as genuine corruption of an interior record (not just a torn tail), and recovery aborts with InvalidData instead of treating it as a truncation boundary.
Solutions
- Restore the volume from the most recent backup or snapshot; the interior record is corrupted and cannot be trusted.
- Re-run recovery from the last known-good commit/footer to rebuild from an earlier consistent point.
- Inspect the file around the reported offset to confirm hardware corruption; run filesystem/disk checks.
- If the corrupted record's data is recoverable from another source, re-write it and re-run recovery.
Defensive patterns
Strategy: fallback
Try / catch
match recover_from_headers(&file) {
Err(e) if e.to_string().contains("invalid interior Astrid volume record length") => {
// fall back to last committed footer/backup; flag volume for inspection
}
other => other?,
} Prevention
- Take regular volume snapshots so you can fall back to a consistent point.
- Run volumes on storage with checksumming (or fs-level integrity) where possible.
- Never manually edit or patch volume files.
- Recover from the last committed footer rather than raw headers when corruption is suspected.
When it happens
Trigger: handle_bad_length (invoked from read_header) sees total_len > remaining AND has_physically_valid_record_after(offset+1) returns true, meaning a plausible record follows a record claiming an impossible length — physical corruption inside the volume, not simple end-of-file truncation.
Common situations: Disk-sector corruption or bit rot flipping bytes in a length field mid-file; a buggy writer previously appended garbage that resembles a valid record header; recovery run on a partially damaged volume after a hardware fault.
Understand the failure class
Background: Checksum mismatch errors: "checksum verification failed", "digest mismatch", "expected vs actual checksum" — what they mean and how to fix them — this error's family across 41 libraries.
Related errors
- invalid Astrid volume record length at
- non-UTF-8 region name
- Astrid volume record checksum mismatch
- audit read failed
- destination.as_str()
AI-assisted analysis of astrid-runtime/astrid@affd8760f4 (2026-09-09).
Data as JSON: /api/errors/fa01c41c91886de2.
Report an issue: GitHub.
Appendix: source
Thrown at crates/astrid-storage/src/volume/hosted/recover.rs:415
logical_offset: u64::from_le_bytes(read_array::<8>(&fixed[27..35])?),
checksum: read_array::<32>(&fixed[43..75])?,
name,
payload_offset,
payload_len,
}))
}
fn handle_bad_length(
file: &File,
offset: u64,
physical_len: u64,
total_len: u64,
remaining: u64,
) -> io::Result<Option<RecordHeader>> {
if total_len > remaining
&& has_physically_valid_record_after(file, offset.saturating_add(1), physical_len)?
{
return Err(io::Error::new(
io::ErrorKind::InvalidData,
format!("invalid interior Astrid volume record length at {offset}"),
));
}
if total_len > remaining {
return Ok(None);
}
Err(io::Error::new(
io::ErrorKind::InvalidData,
format!("invalid Astrid volume record length at {offset}"),
))
}
fn read_record_payload(file: &File, header: &RecordHeader) -> io::Result<Option<Vec<u8>>> {
if header.operation == Operation::Write {
return Ok(None);
}
let max_payload = if header.operation == Operation::Commit {View on GitHub (pinned to affd8760f4)