Artifact Description [576549f588]

Artifact 576549f588124d55efb870df97d2578973027e34cd6a6342ecf669fbe7ce1aed:

• File src/transport.zig
  • 2026-07-31 21:51:35 — part of check-in [b4637e26df] on branch issue22-diagnostics — sync: name the HTTP status the peer answered with

    "the peer answered with an unexpected HTTP status" sends an investigation nowhere. 500 (the server could not build a reply), 413 (the request exceeded the body ceiling), 400 (a malformed container) and 417 (a rejected Expect: 100-continue) are four different bugs, and the message distinguished none of them. Issue #22 has been open on exactly that sentence.

    transport.zig discarded the code at the status check because Zig errors carry no payload and the closed error set is deliberate. Rather than widen TransportError with a variant per status, the status is left on the Transport as last_status for the caller to read after the error, and syncRunFail names it: "the peer answered HTTP 500 (Internal Server Error)".

    Immediately useful: re-running the issue #22 gate against the fossil corpus with this build turns its failure_reason from the old sentence into HTTP 500, which -- together with the reply-size arithmetic -- narrows the cause to OutOfMemory or ServerStorage and eliminates every 4xx path. The issue's own hypothesis, a per-round shun-snapshot readiness problem, is not among the candidates: that arm is documented unreachable and the code agrees.

    Also corrects three comments Slice 2 falsified, all on the same read path:

    logstore's open no longer CRC-verifies payloads, so the serve snapshot's contentImpl/wireImpl read faults are no longer "post-scan EIO or bitrot after a verified scan" -- ordinary stored corruption now reaches serve there, on the read. That is a better shape (one bad frame fails the round that touches it rather than making the server refuse to serve at all) but it makes that arm live traffic, and anything reasoning about how often it fires must start from that.

    runPack and runShun both claimed their read-only open was an "integrity pre-flight" that aborted a corrupt source before a byte was written. It no longer verifies payloads. The guarantee still holds -- packLog pulls every artifact through srcContent, which propagates error.Corrupt rather than skipping the frame, and readFrameAt CRC-checks every read, so a rotted payload still aborts with the temp deleted and .zit untouched -- but it is now collected during the copy loop instead of at open. Both verbs RENAME OVER the original, so runPack's comment now states the consequence plainly: if srcContent is ever changed to answer null on a corrupt read, the rewrite would silently omit the damaged artifact and then delete the only copy of it.

    Verified: fmt clean, test 2327/2327, gate, e2e 671/671. The new message checked against a stub server answering 500. (user: dmestas, size: 25249) [annotate] [blame] [check-ins using]

  • 2026-08-01 14:46:29 — part of check-in [94bebf57f1] on branch trunk — merge issue22-diagnostics: reclone got HTTP 500 on a healthy store

    ReleaseSafe asserts made the clone answer O(store), and serve's 5s deadline raced read + answer + write as one unit -- so a slow answer was cancelled mid-flight and the dead pread surfaced as error.Storage.

    Asserts gone (zit verify covers them); the deadline now races read and write separately. Not scale-dependent -- machine speed vs a wall clock.

    Stalled peer still cut at 5.0s. test/gate/e2e/dst green. (user: dmestas, size: 25249) [annotate] [blame] [check-ins using]

  • 2026-08-01 15:03:25 — part of check-in [c1f44ba0ed] on branch sub-manifest — merge trunk: the issue 22 clone fix reaches the submanifest bench

    Bench now builds ReleaseSafe, which is the mode the O(store) asserts fired in, so without this the clone arm hits them at width. (user: dmestas, size: 25249) [annotate] [blame] [check-ins using]