neuron-technologies/el-retired
Archived
3
0
Fork 0
Code Issues 4 Pull Requests Actions Packages Projects Releases 5 Wiki Activity

runtime divergence: embedding persistence and SIGPIPE exist only in neuron's vendored el_runtime.c #86

New Issue
Open
opened 2026-08-09 15:30:21 +00:00 by tim.lingo · 0 comments
tim.lingo commented 2026-08-09 15:30:21 +00:00
Member
Copy Link
Copy Source

Two copies of el_runtime.c have diverged, and the shared one — which every component except the neuron soul compiles against — is missing two fixes that are already written and proven.

Measured

runtime copy include_emb SIGPIPE handling
el/lang/releases/v1.0.0-20260501/el_runtime.c (shared, what CI pulls) 0 0
el/lang/el-compiler/runtime/el_runtime.c 0 0
neuron/vendor/el-runtime/v1.0.0-20260501/el_runtime.c 5 14

Same version string. Different contents.

Why it matters

Embedding persistence. The engram's own build recipe (.gitea/workflows/*) pulls the runtime from the el release registry, so a correctly-built engram still cannot persist meaning-vectors. On 2026-08-09 a vectorised graph was loaded into the operator's store: it returned {"ok":true}, node counts matched exactly, the save reported success — and every one of 39,957 vectors was silently discarded. Rebuilding the same source against the vendored runtime persisted all 39,957 across a kill -9.

Crash protection. A client hanging up mid-response kills a daemon with no SIGPIPE handling. The operator's soul crashed this way repeatedly on 2026-08-08 (recorded exit signal 13), each crash costing ~25 minutes of unavailability. The fix exists in the vendored copy only.

Consequence

Any component that builds against the shared runtime is permanently behind on both. That is currently everything except the neuron soul, which vendors its own copy.

Ask

Propagate the include_emb and SIGPIPE changes from the vendored copy into lang/releases/v1.0.0-20260501/el_runtime.c, or record a deliberate decision that the vendored copy is authoritative and have other components vendor it too.

We can prepare the PR — flagging rather than pushing unreviewed changes into shared infrastructure we cannot test every consumer of.

Two copies of `el_runtime.c` have diverged, and the shared one — which every component except the neuron soul compiles against — is missing two fixes that are already written and proven. ## Measured | runtime copy | `include_emb` | SIGPIPE handling | |---|---|---| | `el/lang/releases/v1.0.0-20260501/el_runtime.c` (shared, what CI pulls) | **0** | **0** | | `el/lang/el-compiler/runtime/el_runtime.c` | **0** | **0** | | `neuron/vendor/el-runtime/v1.0.0-20260501/el_runtime.c` | **5** | **14** | Same version string. Different contents. ## Why it matters **Embedding persistence.** The engram's own build recipe (`.gitea/workflows/*`) pulls the runtime from the el release registry, so a correctly-built engram still cannot persist meaning-vectors. On 2026-08-09 a vectorised graph was loaded into the operator's store: it returned `{"ok":true}`, node counts matched exactly, the save reported success — and every one of 39,957 vectors was silently discarded. Rebuilding the same source against the vendored runtime persisted all 39,957 across a `kill -9`. **Crash protection.** A client hanging up mid-response kills a daemon with no SIGPIPE handling. The operator's soul crashed this way repeatedly on 2026-08-08 (recorded exit signal 13), each crash costing ~25 minutes of unavailability. The fix exists in the vendored copy only. ## Consequence Any component that builds against the shared runtime is permanently behind on both. That is currently everything except the neuron soul, which vendors its own copy. ## Ask Propagate the `include_emb` and SIGPIPE changes from the vendored copy into `lang/releases/v1.0.0-20260501/el_runtime.c`, or record a deliberate decision that the vendored copy is authoritative and have other components vendor it too. We can prepare the PR — flagging rather than pushing unreviewed changes into shared infrastructure we cannot test every consumer of.
This repo is archived. You cannot comment on issues.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
BETA-CRITICAL
On the beta critical path — must resolve before ship
 HELD
Blocked pending an external decision (counsel / dual sign-off)
 ORTHOGONAL
Parallel workstream (testing/hardening) — safe to assign off critical path
 POST-BETA
Important but not blocking the beta ship
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
andre.almeida (Andre Almeida) tim.lingo (Tim Lingo) will.anderson (Will Anderson)
No Assignees
1 Participants
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: neuron-technologies/el-retired#86
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?