SynapCores v1.14.1.1 — a critical patch worth upgrading for

Sometimes the most important release isn't a feature — it's the one that makes sure the answers you're already getting are correct. v1.14.1.1 is that release. It closes three ways a single ordinary query could return wrong data or take the gateway down. If you're on v1.14.0 or v1.14.1, upgrade.

All three were found the honest way: by building a real compliance application against the shipped image and watching what it did.

1. The silent one: explicit-projection scans could return NULL

This is the one that matters most, because it was invisible. A full-table scan with an explicit column list —

SELECT id, parent_id, status FROM decisions;

— returned NULL for any nullable column whose value was NULL in the very first row ever inserted into the table, for every row, no matter what was actually stored.

SELECT * was correct. Primary-key lookups were correct. WHERE parent_id = '...' matched the real values. The data was never lost — only the explicit-projection read misreported it. In a compliance ledger where the first record written happened to have a NULL parent, that meant every later override read back as an orphan while the links sat correctly in storage the whole time. The app said success; only querying the rows directly revealed the disagreement.

SELECT <columns> now always equals SELECT *. (This one was old — present since at least v1.13 — which is exactly why silent bugs are the dangerous kind.)

2. The loud one: an oversized prompt could take down the whole gateway

Embed a long document — or hand a RAG-style AGENT_RUN a few pages of context — and once it crossed the model's encoder budget (~512 tokens), a native assertion aborted the entire process, for every tenant on the instance. No privilege required; nothing about the request looked unusual.

Now it fails the statement, not the process:

prompt exceeds model input budget: 1402 tokens > 512

The gateway stays up; the caller gets an error it can act on.

3. The agentic one: tool-using agents could crash on Llama models

A single tool-enabled AGENT_RUN / CREATE AGENT / agentic chat could abort the gateway on Llama-family models — a tool-call grammar edge case collapsed the model runtime's grammar stack and threw across the language boundary. The default model wasn't affected, but anyone who switched to a Llama model for agents was exposed. Fixed two ways: the grammar is corrected so agents actually complete, and a guard now converts any native inference exception into a normal error so no future edge case can abort the process.

Drop-in

This is inference/query-layer only — no SQL surface, storage, data-sync, or config changes versus v1.14.1. Upgrade in place:

docker pull synapcores/community:v1.14.1.1-ce
# or:
curl -fsSL https://get.synapcores.com | sh

Validated on the published image: SELECT <cols> ≡ SELECT * on mutable and immutable tables · oversized embed returns an error with the gateway still healthy · tool-loop agents 0/9 aborts · full feature validator 88/88 · recipe certification 158/162, matching the prior release with zero regressions · zero process aborts of any kind.

If you run agents, embed documents, or project named columns — which is to say, if you run SynapCores — this one is for you.