v1.14.5-ce¶
Agent event bindings survive concurrency
A user write that committed while any durable-agent run was in flight lost its event binding, silently. On CPU-only hosts an agent run lasts 45–180 seconds, so on a busy install most writes landed inside that window and their events simply vanished — with nothing in the logs. Measured: 0/2 in-flight before, 2/2 after.
Released: 2026-08-23 · Type: correctness and reliability · Upgrade: drop-in
Agent event bindings were suppressed under load¶
Affects anyone running durable agents with ON INSERT / ON UPDATE bindings
A committed user write landing during an agent run was misclassified as agent-originated and its binding was skipped. No error was raised.
| user INSERT lands | binding fires? |
|---|---|
| engine idle | yes — 2/2 |
| during an agent run | no — 0/2 |
Write provenance lived in a process-global held across the whole send_message future.
That future is dominated by LLM generation — roughly 2s on a hosted API, 45–180s on
CPU — so the suppression window was the entire run, not the write. The louder the
install, the more events disappeared.
The symptom operators reported was "my ON INSERT agent stopped firing", with nothing
to grep for.
Fixed. Provenance is now a per-task marker propagated explicitly across the DML spawn boundary. The process-global remains as a fail-safe backstop, deliberately: the two error directions are not symmetric. A user write misread as the agent's only misses a firing, which is recoverable. An agent write misread as a user's re-fires the agent's own binding — an unbounded, billable loop.
Verified by controlled A/B on live gateways, same harness and same confirmed window, only the binary differing: unfixed 0/2 in-flight, fixed 2/2, idle 2/2 on both.
New runaway backstop
More than 120 event fires per agent per minute are now refused and reported at ERROR.
Override with AIDB_AGENT_MAX_EVENT_FIRES_PER_MIN; 0 disables. Schedules and
WAKE AGENT are never capped.
Recipes executed against the wrong storage¶
/v1/recipes/execute ran every statement against the master operations handle with no
tenant, while /v1/query/execute used the tenant's isolated container. Different storage
trees.
- Tables a recipe created were unreachable from
/v1/query/execute, the SQL console and the SDKs. A recipe that worked looked like it had done nothing. - Every tenant's recipe wrote into one shared tree — an isolation hole on multi-tenant deployments.
Fixed. Recipes now execute through the tenant's own container, scoped to the recipe's current database.
Reloading any page froze the UI¶
Unrecoverable, and silent
A bare spinner, no console error, and reloading only restarted the wait.
The auth bootstrap gated the whole interface on GET /v1/users/me using the API client's
defaults: a 600-second timeout with 3 retries. A gateway that was merely busy — one
saturated by agent inference, which is normal for this product — therefore held every page
behind a spinner for up to roughly 30 minutes. Nothing had failed, so nothing logged.
Fixed. The bootstrap call is bounded to 8s and a single retry. On failure the session clears and the user lands on the login page, which is a recoverable state.
The recipe editor opened blank¶
Editing a saved recipe showed an empty body. The editor read content from the summary
listing — which omits it by design — instead of the detail endpoint that already existed
and already requested the full document.
A clearer error for AI functions in ORDER BY¶
AI functions not supported in sync evaluation named an internal evaluator, never
mentioned ORDER BY, and offered no rewrite.
The real rule is narrow: an AI function cannot appear directly in ORDER BY, because
sort keys are computed by a synchronous evaluator with no way to call a model. Everywhere
else — projections, WHERE, SET, VALUES, INSERT … SELECT — it works.
-- ✗ fails
SELECT id FROM t ORDER BY COSINE_SIMILARITY(a, b) DESC;
-- ✓ works: project it, sort by the alias
SELECT id, COSINE_SIMILARITY(a, b) AS score FROM t ORDER BY score DESC;
The message now names the clause, the function, and the rewrite. This matters more for an
agent than for a person: an agent handed the failing form re-issues the identical query,
trips the repeat-call guard, and its run ends stalled — which reads as a broken model
and is not.
Validation¶
| gate | result |
|---|---|
feature_validator.py (state-asserting) |
188 passed, 0 failed |
| Recipe certification | 156/162, zero regressions vs v1.14.4 |
| Non-AVX-512 canary (i5-10400F) | boots, loads models, EMBED + GENERATE, no SIGILL |
| Published-artifact re-validation | checksum OK, canary green, embedded catalog verified |
Errata¶
Fresh installs seed two fewer recipes
A new install seeds 162 recipes rather than 164. Three agent recipes were deferred pending manual certification and will be published to the recipe site. Existing installs are unaffected — the catalog is seeded only when empty.
Six catalog recipes still fail certification. All are pre-existing and unchanged from
v1.14.4: five are not safe to re-run (duplicate key on a fixed primary key), and one
requires AIDB_IMMUTABLE_MASTER_KEY to be set.
Install¶
Drop-in upgrade: no migration, no configuration change.