Durable runtime response-length fix — kill the truncation bug CLASS (generalize #79) #85
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Tag: POST-BETA · ORTHOGONAL · important
Owner: @tim.lingo
Why
#79 fixed one truncation via a pointer-identity fix, but the underlying class remains: any handler that
fs_reads and then returns a body longer than what it read can truncate the reply. This signature has recurred (neuron #96 safety-contact, neuron-ui #184 Windows stale runtime). Per-handler workarounds don't close the class.Scope
Generalize the fix in the el runtime so response length is governed by the actual body, not by an earlier read buffer / pointer:
fs_read/buffer rather than recomputed from the emitted body.Acceptance criteria
@tim.lingo Confirm the scope with you: the durable fix belongs in the el runtime response path (length governed by the emitted body, not a prior fs_read buffer), not per-handler — agreed? Please coordinate with #79 (the pointer-identity fix this builds on) and #70 (the RSS leak, separate bug).