fix/http-fs-read-len
El SDK Release / build-and-release (pull_request) Failing after 25s
The binary-safe fs_read length (_tl_fs_read_len) was consumed by the HTTP
response path for ANY body, even when the handler wrapped the file into a
larger reply. Content-Length then lied AND the send stopped short: the
safety-contact routes returned 178 of 208/218 bytes, cut mid-'set_at' —
unparseable JSON. The desktop app read that as failure: fresh installs
trapped at 'Set your safety contact' (POST reply mangled) and configured
users saw the gate re-appear every launch (GET reply mangled). Worse, a
stale hint LARGER than a later body would over-read heap memory out the
socket.
Fix: pair the hint with the exact buffer pointer it describes; consume it
only when the response IS that buffer (binary file serving keeps working,
the hint follows the worker's copy); reset both at request start. Also
ports engram_get_node_by_label (from releases/v1.0.0) needed by soul.el
session continuity in local mode — not-found returns "" (matches shipped
behavior; '{}' flips the truthiness check upstream).
Verified: genesis boot + byte-math E2E on :7797 sandbox — safety-contact
GET/POST/GET all Content-Length==body, json-parse clean; /health,
/api/config regressions match.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Description
The Engram programming language — types as knowledge nodes, quantum-sealed prod target
147 MiB
Releases
5
El SDK (latest)
Latest
Languages
Emacs Lisp
74.6%
C
21.9%
HTML
1.5%
Objective-C
0.6%
Shell
0.6%
Other
0.8%