Skip to content

Bounded query execution: /v1/query OOM fix (LLP 0054-0059) [blocked by upstream]#221

Draft
philcunliffe wants to merge 4 commits into
masterfrom
integration/bounded-query-execution
Draft

Bounded query execution: /v1/query OOM fix (LLP 0054-0059) [blocked by upstream]#221
philcunliffe wants to merge 4 commits into
masterfrom
integration/bounded-query-execution

Conversation

@philcunliffe

@philcunliffe philcunliffe commented Jun 30, 2026

Copy link
Copy Markdown
Contributor

Kernel fix for the /v1/query OOM. Implements the bounded-query-execution change set: spec LLP 0054, decisions 0055/0056, plan 0057 (human) → design 0058 + executable plan 0059 (neutral). See llp/0058-bounded-query-execution.design.md for the technical design and llp/0059-…plan.md for the task breakdown.

⛔ Blocked by (must be merged AND published to npm first)

This change set spans three repos. The kernel tasks below pin exact versions, so they cannot build/test until the upstream features ship:

This PR stays draft + labelled neutral:stuck until both upstream PRs are merged + published; it is blocked by an external dependency, not a failed attempt. Once the new versions are published, neutral bumps the pins and lands the remaining tasks, then drives this to held for review.

Task status (LLP 0059)

task what status
T1 kernel signal threading (forward AbortSignal into squirrelExecuteSql; sql.js:115) ✅ in this PR — works against the current pinned squirreling (already threads signal); green
T2 icebird scanColumn ⬆️ upstream — icebird#28 (held)
T3 core union scanColumn forward (union-source.js) ⏳ pending icebird publish
T4 ai-gateway withSchemaColumns forward (dataset.js) ⏳ pending icebird publish
T5 streaming aggregates end-to-end ⏳ pending icebird publish
T6 squirreling budget ⬆️ upstream — squirreling#42 (held)
T7 kernel budget option + typed-error re-export ⏳ pending squirreling publish
T8 wire CLI/MCP callers + budget telemetry ⏳ pending T7
T9 bounded_query_refusal acceptance smoke ⏳ pending T5+T7

Change-Set: bounded-query-execution

philcunliffe and others added 2 commits June 30, 2026 14:50
@philcunliffe @claude
Design: bounded query execution (LLP 0058)
5bd256b 
Mint the missing `design` LLP for the /v1/query OOM kernel-fix package.
The package shipped spec (0054) + decisions (0055/0056) + prose plan
(0057) with no design-type doc, so `neutral backlog` flagged 0054 as
needing a design.

LLP 0058 ties the spec to a concrete technical design grounded in the
real query kernel: the buffering OOM site at `src/core/query/sql.js`
(`squirrelExecuteSql` called with no signal, then `collect()`), the
dead `context.signal` abort path, the dormant `scanColumn` aggregate
fast path no kernel source implements, and the display-only
`ContextControls` budget. It lays out signal threading, streaming
aggregates via `scanColumn` down the source stack (per 0055), and the
refuse-over-budget execution budget (per 0056), citing the decisions
rather than restating them.

@ref LLP 0054 (implements, coverage) / 0055, 0056 (constrained-by).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@philcunliffe @claude
Plan: bounded query execution executable tasks (LLP 0059)
a033960 
Mints the neutral executable plan for the /v1/query OOM kernel fix
change set: a ## Tasks breakdown that extends the prose plan LLP 0057
and implements the technical design LLP 0058. Nine independently
mergeable tasks across the three design mechanisms (signal threading,
scanColumn down the source stack, execution budget with refusal),
their two upstream engine PRs (icebird, squirreling), caller wiring,
and an end-to-end memory-invariant smoke.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@philcunliffe philcunliffe added the neutral:stuck neutral attempted this but cannot complete it autonomously — needs a human label Jun 30, 2026
@philcunliffe

philcunliffe commented Jun 30, 2026

Copy link
Copy Markdown
Contributor Author

🤖 neutral: blocked by upstream (held — not a failure)

Labelled neutral:stuck only to hold this PR from auto-advancing while it waits on the two upstream PRs — it is blocked by an external dependency, not a failed attempt. This is the hypaware side of a 3-repo change set:

What happens when you publish: drop the neutral:stuck label (or just tell me), and neutral will bump the exact pins (icebird, squirreling), land the remaining tasks (T3/T4 scanColumn forwarding, T5 streaming aggregates, T7 budget option, T8 callers, T9 acceptance smoke), then drive this PR through review to held for your merge.

T1 (signal threading) lands here now — it works against the current pinned squirreling and is independently useful.

philcunliffe and others added 2 commits June 30, 2026 16:21
@philcunliffe @claude
Kernel signal threading: forward an AbortSignal into the SQL engine (…
8f299fc 
…T1, LLP 0059)

executeQuerySql now composes the caller-supplied `signal` with an optional
relative `timeoutMs` deadline (via AbortSignal.timeout/AbortSignal.any) and
forwards it as squirrelExecuteSql({ tables, query, signal }) at the call site
that previously omitted it. squirreling@0.12.24 already threads `signal` through
`context.signal` to its blocking operators (sort.js, aggregates.js) and the leaf
parquet scan honors it at the row-group boundary, so this wiring is the whole
fix: a long or runaway query can now be torn down mid-scan instead of running to
completion. This is the abort enabler only; it bounds nothing on its own (the
execution budget and refusal are T6/T7).

Add `signal?` and `timeoutMs?` to ExecuteSqlOptions. Annotate the call site with
@ref LLP 0054#signal-threading [implements].

Tests (test/core/query-sql-signal.test.js): a caller-aborted signal tears down a
running query mid-scan; an already-aborted signal stops it before completion; a
timeoutMs deadline aborts a slow query; and a normal no-signal query still
returns all rows (backward compatible).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@philcunliffe
Merge task T1 (signal threading) into integration/bounded-query-execu…
eedf6ca 
…tion
@philcunliffe

philcunliffe commented Jul 7, 2026

Copy link
Copy Markdown
Contributor Author

🤖 neutral: stuck — blocked by upstream (held, not a failure)

What neutral was doing: driving the bounded-query-execution change set (spec LLP 0054, decisions 0055/0056, plan 0057 → design 0058 + plan 0059) toward held+green+reviewed. Head eedf6ca. T1 (kernel signal threading) is landed here and green; CI is all-green.

Why it cannot proceed: this is the hypaware slice of a 3-repo change set. The remaining kernel tasks pin exact upstream versions that do not exist on npm yet, so they cannot build or test:

Both upstream PRs are held/reviewed/green and waiting on your merge + npm publish. This is an external-dependency block, not a failed attempt — nothing here for a worker to retry.

What it needs from you: merge and npm publish the two upstream PRs (icebird#28, squirreling#42).

How to unstick: once the new icebird / squirreling versions are published, reply on this thread (or drop the neutral:stuck label, or push to the branch). neutral monitors this thread and will re-engage next tick — bump the exact pins, land the remaining tasks (T3/T4 scanColumn forwarding, T5 streaming aggregates, T7 budget option, T8 callers, T9 acceptance smoke), then drive this PR through review to held for your merge.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

neutral:stuck neutral attempted this but cannot complete it autonomously — needs a human

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@philcunliffe