shredstream.sh error code reference
Interpret account API codes, uncoded HTTP failures, verification failures, and receiver-local UDP and shred conditions with a concrete remediation for each.
Response shape
Current account API failures represented by a service error use a JSON object with error and code fields plus the HTTP status shown below. An unexpected server failure returns HTTP 500 with a generic error message and no documented code field.
UDP has no response channel. The live stream does not emit service error records. Receiver failures therefore appear as missing traffic, kernel counters, parser rejections, or application metrics.
Account API codes
The login-session status endpoint can return HTTP 401 with signedIn false and no code field. Treat that as an unauthenticated session condition, not as a malformed JSON response.
Uncoded HTTP conditions
Verification and delivery conditions
The labels in this table are a recommended receiver vocabulary. They are not datagrams returned by shredstream.sh.
Datagram and kernel conditions
Shred parser and validator conditions
Recovery, ordering, and decode conditions
Logging rule
Aggregate high-rate conditions by code, source, slot range, variant, and time window. Keep bounded packet samples for structural failures and duplicate conflicts. Do not write one log line per invalid packet at feed rate because logging can create the next receive overflow.
Questions
- Does the UDP stream send error messages?
- No. UDP delivery has no response channel and the documented live payload is a raw Solana shred, not a service envelope. Delivery failures appear as missing packets, network counters, socket drops, parser rejections, or stale application state. The receiver-local labels on this page provide a consistent diagnostic vocabulary.
- What should an integrator do with fanout_error?
- Read both the returned HTTP status and error message because fanout_error represents a non-success response passed through from delivery control. Do not assume every instance is retryable. Preserve current account state, avoid duplicate mutations, and retry only when the status, message, and operation make repetition safe.
- Why are duplicate and duplicate_conflict separate?
- An identical duplicate is expected in multi-path or repeated delivery and can be reduced to the earliest valid copy. A conflicting duplicate carries different bytes under the same cluster, slot, shred type, and index. Silent overwrite would destroy evidence of corruption, context error, or authenticated equivocation.