rtk-ai/rtk · error · anyhow::Error
negative record length: {}
Error message
negative record length: {} What it means
While scanning auxiliary records (NameValueList / ProjectImportArchive), the record's 7-bit-encoded length reads as a negative i32. Binlog record lengths are unsigned quantities, so a negative value means the parser has desynchronized from the stream.
Source
Thrown at src/cmds/dotnet/binlog.rs:353
.read_7bit_i32()
.context("failed to read record kind")?;
if kind == RECORD_END_OF_FILE {
break;
}
match kind {
RECORD_STRING => {
let text = reader
.read_dotnet_string()
.context("failed to read string record")?;
parsed.string_records.push(text);
}
RECORD_NAME_VALUE_LIST | RECORD_PROJECT_IMPORT_ARCHIVE => {
let len = reader
.read_7bit_i32()
.context("failed to read record length")?;
if len < 0 {
anyhow::bail!("negative record length: {}", len);
}
reader
.skip(len as usize)
.context("failed to skip auxiliary record payload")?;
}
_ => {
let len = reader
.read_7bit_i32()
.context("failed to read event length")?;
if len < 0 {
anyhow::bail!("negative event length: {}", len);
}
let payload = reader
.read_exact(len as usize)
.context("failed to read event payload")?;
let mut event_reader = BinReader::new(payload);
let _ =View on GitHub (pinned to 36788f6bd4)
Solutions
- Regenerate the binlog — treat the existing file as corrupt
- Confirm the build that produced it completed and flushed the file (no kill/disk-full)
- Check the file is a real binlog (magic header present) and not an arbitrary file
- If reproducible with a valid file, report the parser bug at the producing record boundary
Defensive patterns
Strategy: try-catch
Try / catch
match parse_events_from_binlog(&path) {
Ok(b) => use_events(&b),
Err(e) if e.to_string().contains("negative record length") => {
eprintln!("binlog corrupt; falling back to raw dotnet output");
run_raw_dotnet(args)
}
Err(e) => return Err(e),
} Prevention
- Verify artifact checksums before parsing
- Never truncate/kill a build mid-write
- Regenerate the binlog instead of retrying a corrupt file
When it happens
Trigger: parse_events_from_binlog encounters RECORD_NAME_VALUE_LIST or RECORD_PROJECT_IMPORT_ARCHIVE whose encoded length decodes negative — nearly always from a corrupted or truncated payload, or reading a file whose claimed length ran past the buffer.
Common situations: Binlog damaged by partial download/copy; file truncated mid-write; feeding a non-binlog file to the parser so offsets land mid-data.
Related errors
- negative event length: {}
- invalid 7-bit encoded integer
- negative string length: {}
- unexpected end of stream
- Failed to parse binlog at {}: empty file
AI-assisted analysis of rtk-ai/rtk@36788f6bd4 (2026-09-03).
Data as JSON: /api/errors/65faa332af893095.
Report an issue: GitHub.