feat(apps): add execution tables to local + cloud drizzle schemas#400
Draft
aryasaatvik wants to merge 4 commits intoRhysSullivan:mainfrom
Draft
feat(apps): add execution tables to local + cloud drizzle schemas#400aryasaatvik wants to merge 4 commits intoRhysSullivan:mainfrom
aryasaatvik wants to merge 4 commits intoRhysSullivan:mainfrom
Conversation
Adds execution history persistence to the core SDK surface, wiring
three new tables (`execution`, `execution_interaction`,
`execution_tool_call`) into `coreSchema` and exposing an
`ExecutionStore` service on `executor.executions`.
Changes:
- `core-schema.ts`: three new tables with `scope_id` / `execution_id`
/ `tool_path` / `trigger_kind` / `created_at` indexes for the runs
UI's faceting + timeline queries.
- `ids.ts`: branded `ExecutionId`, `ExecutionInteractionId`,
`ExecutionToolCallId`.
- `executions.ts`: `Execution`, `ExecutionInteraction`,
`ExecutionToolCall` Schema classes, status enums,
create/update/filter/sort/meta input types, and the
`ExecutionStore` Context.Tag.
- `execution-store.ts`: `makeExecutionStore(core)` — an
adapter-backed `ExecutionStoreService` implementation. Wraps
`typedAdapter<CoreSchema>` for CRUD, handles cursor-based
pagination, filter predicates (status, trigger, tool-path glob,
time range, code substring, hadElicitation), and builds list meta
with facets + chart buckets.
- `cursor.ts`: base64url `{ createdAt, id }` pagination cursors.
- `executor.ts`: constructs the store once per executor, exposes via
`executor.executions`.
- `executions.test.ts`: round-trip + lifecycle coverage against the
in-memory adapter (no migrations needed).
Follow-up work (future PRs in the stack):
- wire the engine to record runs + tool calls through this store,
- add `/executions` API endpoints, and
- land the runs UI.
This was referenced Apr 24, 2026
aryasaatvik
force-pushed
the
feat/app-drizzle-schemas-executions
branch
from
c643404 to
5d8f251
Compare
Wires `executor.executions` into the Effect-native engine so every
`execute()` / `executeWithPause()` / `resume()` call writes an
`execution` row and its associated tool-call + interaction rows to
whichever `DBAdapter` backs the SDK.
Engine additions:
- `ExecutionTrigger` type + new `trigger?` option on `execute` and
`executeWithPause`. Callers attribute runs ("cli", "http", "mcp",
…); the kind + optional meta blob are persisted on the row.
- A stable `crypto.randomUUID()` execution id is minted at entry and
reused as `PausedExecution.id`, so callers and the DB share the
same identifier and counts line up across pause/resume.
- `makeRecordingInvoker` wraps the `SandboxToolInvoker` passed to the
code executor; each `invoke` writes a tool-call row (running →
completed|failed with duration). Storage errors are ignored so
bookkeeping failures can never fail the tool call itself.
- `persistTerminalState` runs once on fiber success or failure and
writes final status, result/error, logs, toolCallCount, completedAt.
- Pausable path: on elicitation, the execution transitions to
`waiting_for_interaction` and a pending interaction row is created;
`resume` resolves it (or cancels it if action === "cancel") before
unblocking the fiber. A `toolCallCounters` map keeps the same Ref
across pause/resume so the final count is accurate.
- Inline path: wraps the caller-supplied `onElicitation` so every
inline elicitation gets the same pending → resolved bookkeeping.
Tests (`engine-persistence.test.ts`, 5 cases) cover:
- completed run + tool call rows
- error result → status=failed, errorText captured
- toolCallCount rolls up correctly
- trigger kind + meta persist on the row
- failed tool call records status=failed with errorText
Flows the trigger: { kind, meta } option the engine added in the
previous PR end-to-end so the runs UI can facet by attribution
surface. Also promotes recording writes from Effect.ignore to a
defect-absorbing variant so a misconfigured storage backend can't
take down an execution.
Surfaces:
- HTTP API (packages/core/api): /executions POST now declares an
x-executor-trigger optional header. Handler reads it (defaulting to
"http") and passes it as the engine's trigger option.
- MCP host (packages/hosts/mcp): explicit trigger: { kind: "mcp" } on
engine.execute (inline elicitation path) and engine.executeWithPause
(paused flow).
- CLI: stamps every /executions call from executeCode with
x-executor-trigger: cli. Covers call, search, describe, sources —
every subcommand that runs code goes through this helper.
Engine robustness:
- Introduced silent helper (Effect.catchAllCause(() => Effect.void))
and swapped every bookkeeping .pipe(Effect.ignore) over to it.
Effect.ignore only catches typed failures; a synchronous throw
inside an adapter (e.g. storage-drizzle when the schema is missing
the execution model) becomes a defect and was bypassing ignore.
With silent, misconfigured storage just means no row — the
execution itself succeeds.
Verified by the MCP stdio integration test which previously leaked
the [storage-drizzle] unknown model error into the MCP tool result
text. Now returns the expected code result.
aryasaatvik
force-pushed
the
feat/app-drizzle-schemas-executions
branch
from
5d8f251 to
56a022a
Compare
Adds the three `execution*` tables to both app drizzle schemas (sqlite + postgres) so `executor.executions` writes actually land on disk in real deployments. Until this PR, persistence silently no-op'd because the `storage-drizzle` adapter throws on unknown models (absorbed by the engine's `silent` wrapper but no row gets written). - `apps/local/src/server/executor-schema.ts`: three sqlite tables matching the DBSchema shape from `@executor/sdk` (scope_id PK on execution, standalone PK on child rows, matching indexes for scope / status / trigger_kind / created_at / tool_path / namespace). - `apps/cloud/src/services/executor-schema.ts`: mirror in pg-core with `bigint` for epoch-ms columns and `timestamp` for Date columns. - Fresh `drizzle-kit generate` output on each app's `drizzle/` dir (local `0004_fancy_red_wolf.sql`, cloud `0006_panoramic_mother_askani.sql`). No test changes — the MCP stdio integration test already exercises this path end-to-end (runs `return 2+2` through the daemon, which now successfully records + returns "4" as expected).
aryasaatvik
force-pushed
the
feat/app-drizzle-schemas-executions
branch
from
56a022a to
b8c6ac6
Compare
This was referenced Apr 24, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stack
Depends on #399 → #398 → #396 — merge those first. Cross-fork GitHub PRs can't use a branch on a contributor fork as a base, so these five PRs display as independent in the UI. The real dependency chain is the commit graph.
feat(sdk): ExecutionStore backed by DBAdapterfeat(execution): persist engine runs + tool callsfeat(execution): trigger propagation (CLI/HTTP/MCP)feat(apps): execution tables in drizzle schemasfeat(api): /executions list/get/tool-calls endpointsUntil #399, #398, and #396 land, this diff includes their commits. After all three merge, this diff shrinks to just the schema + migration files.
Summary
Adds the three
execution*tables to both app drizzle schemas (sqlite + postgres), plus thedrizzle-kit generateoutput, soexecutor.executionswrites land on disk in real deployments.Until this PR, persistence silently no-op'd —
storage-drizzlethrows on unknown models, and the engine'ssilentwrapper (added in #399) absorbs the defect. Tests against the in-memory adapter pass (that's what the earlier PRs verify), but nothing gets persisted in a production setup.What ships in this PR
apps/local/src/server/executor-schema.ts(sqlite):execution:[scope_id, id]PK; indexes onscope_id,status,trigger_kind,created_at.execution_interaction: standaloneidPK (tenant isolation flows through parent execution); indexes onexecution_id,status.execution_tool_call: standaloneidPK; indexes onexecution_id,tool_path,namespace.apps/cloud/src/services/executor-schema.ts(pg-core): mirror withbigintfor epoch-ms columns (started_at,completed_at,duration_ms,tool_call_count) andtimestampfor Date columns (created_at,updated_at).Generated migrations:
apps/local/drizzle/0004_fancy_red_wolf.sqlapps/cloud/drizzle/0006_panoramic_mother_askani.sqlNo changes to the DBSchema contract in
@executor/sdk— that already declared these tables in #396. This PR just wires physical Drizzle tables that match.Test plan
bun x vitest runin@executor/sdk— 97/97.bun x vitest runin@executor/execution— 15/15.bun x vitest runin@executor/hosts/mcp— 23/23 including the stdio integration test that spawns the real CLI + apps/local daemon, runsreturn 2+2over MCP, and (now) actually persists the execution row in addition to returning4.bun x tsc --noEmitin both apps — clean.