What causes "Truncated: length {} > bytes available {}" in openzipkin/zipkin?

Compare the payload's declared lengths against its actual size at the producer; log both.

openzipkin/zipkin · error · IllegalArgumentException

Truncated: length {} > bytes available {}

Error message

Truncated: length {} > bytes available {}

What it means

ReadBuffer.require(byteCount) is called before every fixed-size read (IDs, timestamps, fixed32/64 fields); when fewer bytes remain than the field needs it throws 'Truncated: length N > bytes available M'. It means the payload ended in the middle of a span — a length prefix promised more data than the transport delivered.

Source

Thrown at zipkin/src/main/java/zipkin2/internal/ReadBuffer.java:375

    byte b; // negative number implies MSB set
    if ((b = readByte()) >= 0) {
      return b;
    }

    long result = b & 0x7f;
    for (int i = 1; b < 0 && i < 10; i++) {
      b = readByte();
      if (i == 9 && (b & 0xf0) != 0) {
        throw new IllegalArgumentException("Greater than 64-bit varint at position " + (pos() - 1));
      }
      result |= (long) (b & 0x7f) << (i * 7);
    }
    return result;
  }

  final void require(int byteCount) {
    if (this.available() < byteCount) {
      throw new IllegalArgumentException(
        "Truncated: length " + byteCount + " > bytes available " + this.available());
    }
  }

  int checkReadArguments(byte[] dst, int offset, int length) {
    if (dst == null) throw new NullPointerException();
    if (offset < 0 || length < 0 || length > dst.length - offset) {
      throw new IndexOutOfBoundsException();
    }
    return Math.min(available(), length);
  }
}

View on GitHub (pinned to 878ce2a1fa)

Solutions

Compare the payload's declared lengths against its actual size at the producer; log both.
Raise or fix transport limits (spring.servlet.multipart.max-request-size, Kafka max.message.bytes, DB column type BLOB vs MEDIUMBLOB) so truncation cannot happen.
Verify checksums/length framing end-to-end (Content-Length, TLS, producer acks) for large batches.
Re-send the batch from the source; truncated data is unrecoverable and must be dropped.

Example fix

# before (zipkin-server)
# default multipart limits truncated large JSON/proto uploads

# after
server.tomcat.max-http-form-post-size=-1
spring.servlet.multipart.max-file-size=100MB
spring.servlet.multipart.max-request-size=100MB

Defensive patterns

Strategy: validation

Validate before calling

// before decode, if the format carries a declared length, compare it
boolean isComplete(byte[] payload, int declaredLen) { return payload.length >= declaredLen; }

Try / catch

catch (IllegalArgumentException e) { if (e.getMessage().startsWith("Truncated")) { LOG.error("truncated span batch: {}", e.getMessage()); requestResend(); } }

Prevention

Size transport limits above your max span batch (HTTP body caps, Kafka max.message.bytes, DB BLOB size).
Use Content-Length and verify byte counts on both ends.
Do not retry truncated payloads — re-ingest from the source.

When it happens

Trigger: Decoding a proto3/thrift span whose declared field length (or the outer list length) exceeds the actual byte count: cut-off HTTP bodies, partial Kafka messages, rows truncated by a storage max-size setting, or a producer bug writing lengths larger than the data.

Common situations: Server/collector request-size limits silently truncating bodies; network interruptions on large span batches; a database column too small for the blob so only a prefix was stored.

Related errors

AI-assisted analysis of openzipkin/zipkin@878ce2a1fa (2026-08-14). Data as JSON: /api/errors/f19e76741733d5e2. Report an issue: GitHub.