| Comment: | serve: deadline bounds peer I/O, not our own answer
The 5s per-connection deadline raced read + answer + write as one unit, so a slow answer was indistinguishable from a stalled peer -- and cancelling mid-answer surfaced as error.Storage, telling the peer the repository was damaged. Issue #22. Read and write are raced separately, each with the full deadline; the answer runs unraced since it is bounded by the store, not the peer. Verified: a peer that sends one body byte and stalls is still cut at 5.0s; pikchr reclone passes. test 2327/2327, gate, e2e 671/671, dst 6x1000, fuzz serve_request_garbage. |
|---|---|
| Timelines: | family | ancestors | descendants | both | issue22-diagnostics |
| Files: | files | file ages | folders |
| SHA3-256: |
73bdc2fef12d4d8380f428bea319969b |
| User & Date: | dmestas on 2026-08-01 12:20:05.701 |
| Other Links: | branch diff | manifest | tags |
|
2026-08-01
| ||
| 14:46 |
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. check-in: 94bebf57f1 user: dmestas tags: trunk | |
| 12:20 |
serve: deadline bounds peer I/O, not our own answer
The 5s per-connection deadline raced read + answer + write as one unit, so a slow answer was indistinguishable from a stalled peer -- and cancelling mid-answer surfaced as error.Storage, telling the peer the repository was damaged. Issue #22. Read and write are raced separately, each with the full deadline; the answer runs unraced since it is bounded by the store, not the peer. Verified: a peer that sends one body byte and stalls is still cut at 5.0s; pikchr reclone passes. test 2327/2327, gate, e2e 671/671, dst 6x1000, fuzz serve_request_garbage. closed check-in: 73bdc2fef1 user: dmestas tags: issue22-diagnostics | |
| 12:06 |
sync: drop the O(store) asserts from the clone answer path
Under runtime_safety (ReleaseSafe -- the shipped build) emitCloneReply reconstructed every served artifact and its delta basis just to assert a declared size. That pushed a clone round past serve's 5s per-connection deadline, which cancels mid-answer; the in-flight pread then failed and the peer got HTTP 500 on a healthy store. Issue #22. zit verify checks the same properties on demand, which is where O(store) verification belongs. Also names the failure server-side: serve collapses every AnswerError into a bare 500, so serveAnswer now logs which one. Reclone verified green: wapp 1038, althttpd 1695, pikchr 2842, libfossil 17218 (18 rounds). test 2327/2327, gate, e2e 671/671, dst 6x1000. check-in: 879b867bb1 user: dmestas tags: issue22-diagnostics | |