will.anderson
43636aed99
El SDK Release / build-and-release (pull_request) Failing after 7s
The binary-safe fs_read length (_tl_fs_read_len) was consumed by the HTTP response path for ANY body, even when a handler wrapped a smaller file into a larger reply. Content-Length then lied AND the send stopped short: the safety-contact (988) routes returned 178 of 208/218 bytes, cut mid-'set_at' — unparseable JSON. The desktop app read that as failure. On Windows the shipped brain is an OLD build without even the per-handler workaround, so EVERY reply truncated: the app can't read confirmations and refuses the new user. Durable fix: pair the length hint with the exact buffer pointer it describes (_tl_fs_read_buf). Apply the raw byte count ONLY when the response IS that buffer (binary file serving stays correct); every wrapped/enveloped/derived body is measured with strlen. Reset both at request start and in fs_read / json_get_raw. This also closes the stale-hint heap over-read (a length larger than a later body would read past it out the socket) that a plain max() leaves open — so this class of bug dies on every platform, not just where a handler happened to be patched. Applied identically to the mainline runtime (lang/el-compiler/runtime) AND the frozen release runtime (lang/releases/v1.0.0-20260501) the desktop souls compile against — the release copy still carried the raw leak, which is why the Windows brain kept truncating. Same proven approach as PR #78 (Tim Lingo), extended to cover the release runtime and rebased onto current main. Both runtimes: gcc -fsyntax-only clean.