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

  1. Regenerate the binlog — treat the existing file as corrupt
  2. Confirm the build that produced it completed and flushed the file (no kill/disk-full)
  3. Check the file is a real binlog (magic header present) and not an arbitrary file
  4. 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

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


AI-assisted analysis of rtk-ai/rtk@36788f6bd4 (2026-09-03). Data as JSON: /api/errors/65faa332af893095. Report an issue: GitHub.