engram: fix silently-wrong query params + make el_seed.o/el_runtime.o link #124
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: neuron-technologies/el#124
Reference in New Issue
Block a user
Delete Branch "fix/engram-query-param-and-seed-link"
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?
Three real bugs, each verified by running the built binary against a copy of the real store — not by reading code.
1. query_param never URL-decoded.
/api/search?q=neural%20networksearched for the literalneural%20networkand returned[]. Every multi-word search against the live engram has been silently returning empty results. Empty, not an error — which is why nobody caught it. Affects every GET route reading query params.Before/after on the same store copy:
[]2. query_param matched key names unanchored.
str_index_of(qs, "q=")matches insidefaq=, so?faq=X&q=Yreturned X for keyq. Verified live before fixing. Now matches&key=against"&"+querystringso it can only land on a real parameter boundary.3. el_request_start/el_request_end defined twice. Both el_seed.c and el_runtime.c defined them, so linking the two objects together — exactly what the product build does — failed on duplicate symbols. el_seed.c's own comment says they moved there; the el_runtime.c copies were leftovers. Also added the three missing prototypes (engram_op_assert_json, engram_node_full_in, engram_connect_in) el_seed.c wraps but never declared, which broke its standalone compile under C99+.
Live engram on :8742 was never touched — all testing was against an isolated copy on port 18742.
Three real bugs, all found by actually running the thing rather than reading it. 1. query_param never URL-decoded. A GET of /api/search?q=neural%20network searched for the literal string "neural%20network" and returned []. Every multi-word search against the live engram has been silently returning empty results — not an error, an empty result, which is why it went unnoticed. Affects every GET route that reads query params, not just search. 2. query_param matched key names unanchored. str_index_of(qs, "q=") matches inside "faq=", so "?faq=X&q=Y" returned X for key "q". Verified live before the fix. Now searches for "&key=" against "&"+querystring so a match can only land on a real parameter boundary. 3. el_request_start/el_request_end were defined in BOTH el_seed.c and el_runtime.c, so linking the two objects together — which is exactly what the product build does — failed with duplicate symbols. el_seed.c's own comment already says these moved there ("formerly defined in el_runtime.c. Now self-contained in el_seed.c"); the el_runtime.c copies were left behind during that move. Removed them, kept declarations since http_worker calls them. Also added the three missing prototypes (engram_op_assert_json, engram_node_full_in, engram_connect_in) that el_seed.c wraps but never declared, which made it fail to compile standalone under C99+. Verified: engram builds and links clean from canonical source; before/after comparison on a copy of the real store shows "neural network" returning a real match where the live build returns [], and "?faq=WRONG&q=MetaColloc" now resolving to MetaColloc. Live engram on :8742 was never touched.