test(storage-boundary): add write-side WIT boundary test#1
Open
zacharywhitley wants to merge 1 commit into
Open
test(storage-boundary): add write-side WIT boundary test#1zacharywhitley wants to merge 1 commit into
zacharywhitley wants to merge 1 commit into
Conversation
Adds `tests/write_boundary.rs` -- the mirror-image counterpart to the read-side `tests/boundary.rs`. Loads the synthetic ducklink writer bridge (companion to sqlink's `synthetic-mutating-vtab-bridge`) and drives its exported `duckdb:extension/storage-write-dispatch@2.0.0` interface end-to-end across the WIT component boundary via wasmtime, covering the full mutating path: begin-transaction, create-table, insert-rows, update-rows, delete-rows, commit-transaction, and the rollback path. The write world is `duckdb:extension@2.0.0`; the pre-existing wit/ tree uses the unversioned `duckdb:extension` package. Rather than version-mix, the write-side WIT lives in a sibling `wit-write/` dir with its own duckdb:extension@2.0.0 dependency, keeping the two bindgen! invocations independent. Bridge wasm is located via (1) $DUCKLINK_WRITER_BRIDGE_WASM, (2) `../../artifacts/extensions/synthetic_mutating_ducklink.wasm` (the staged copy convention), or (3) the sibling checkout at `~/git/synthetic-mutating-vtab-ducklink-bridge/target/wasm32-wasip2/ release/synthetic_mutating_ducklink_bridge_dynlink.wasm`. Test panics with a clear build-me message if none of those exist.
zacharywhitley
pushed a commit
that referenced
this pull request
Jul 21, 2026
Adds `ducklink_load(name)` as a table function on the workspace CLI so the
extension's control-plane surface — committed in `ducklink-extension`'s
`STABILITY.md § 1.1` — is callable from SQL against the workspace host too.
Bumps the conformance suite's `01-entry-points-registered.out` from 2/6 to
3/6 (`ducklink_help`, `ducklink_load`, `ducklink_version`).
Design: host-synthesized table registration + native dispatch intercept.
The wasm DuckDB core hooks LOAD via `host-extension-loader.request-load`;
there is no SQL-callable route from a component into the extension load
orchestration without breaking the frozen `duckdb:extension@4.0.0`
contract, and macros can't have LOAD side effects. So the host takes the
same shape it already uses for the resolver observability scalars: a
sentinel `callback_handle` (`DUCKLINK_LOAD_HANDLE = 0xFFFF_FFFD`) that the
core knows nothing about, injected as a synthetic `reg::TableReg` in
`drain_pending_registrations`. `dispatch_table` short-circuits the sentinel
and runs `ensure_extension_loaded` natively.
The wasm core's runtime WIT registers every `funcarg` as a required
positional parameter (`duckdb_table_function_add_parameter`, no
named-parameter distinction) — so only the positional `name` argument is
surfaced today. `kind => 'wasm'|'native'` from STABILITY § 1.1 is parsed
if a second positional VARCHAR arrives (native currently errors clean —
the workspace has no native tier yet); a future contract bump that adds
named-parameter metadata to `runtime.table-registry.register` lets us
surface the named form without other changes.
Deferred drain: `dispatch_table` runs inside a `call_table` callback, so
the wasm store is mid-call — the same re-entrancy shape the live-query
import respects in `query`. Re-issuing `LOAD <name>;` from the handler
would self-deadlock. So the handler stashes what it loaded on the
manager and `HostState::execute` replays an idempotent `LOAD <name>;`
before the user's next statement; that second LOAD hits
`ensure_extension_loaded`'s already-loaded fast path and the core's
post-LOAD `get_pending_registrations` picks up the stashed
`deferred_registrations` — the extension's functions become visible on
the statement after `ducklink_load` returns (parity with the extension's
"NEXT statement's binder resolves them" contract).
Errors: `FROM ducklink_load('does-not-exist')` returns
`Duckerror::Invalidargument` with a legible message pointing at the
missing manifest entry / <extensions-dir>/*.wasm shortcut; no crash.
`FROM ducklink_load('jsonfns')` returns a single row
`(name, path, scalars, tables, aggregates)` matching the extension's
column shape (path is NULL until the workspace resolver's artifact path
is surfaced — parity follow-up).
Return columns are forward-compatible with `prefix__name` retirement
(task #1 in the fan-out) — no `prefix_*` machinery is added or removed.
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.
Summary
Adds
crates/storage-boundary-test/tests/write_boundary.rsand the companionwit-write/tree (256 + 242 LOC). This is the mirror-image counterpart to the read-sidetests/boundary.rs: it loads the synthetic ducklink writer bridge and drives the exportedduckdb:extension/storage-write-dispatch@2.0.0interface end-to-end across the WIT component boundary via wasmtime, covering begin-transaction, create-table, insert-rows, update-rows, delete-rows, commit-transaction, and the rollback path.The write world is
duckdb:extension@2.0.0; the pre-existingwit/tree uses the unversionedduckdb:extensionpackage. Rather than version-mix, the write-side WIT lives in a siblingwit-write/dir with its ownduckdb:extension@2.0.0dependency, keeping the twobindgen!invocations independent.Cherry-picked as a single commit from
feat/python-sdk-authoring-api(which carries unrelated Python-SDK authoring work) onto a fresh branch offmainso the review scope is just the write-boundary test.Related work
Motivating commits on the sqlink side (writer symmetry):
tegmentum/sqlink@5cfc37dc-- iVersion fixtegmentum/sqlink@6ec38652-- read/write unifyCompanion smoke-fixture repos:
tegmentum/synthetic-mutating-vtab-bridge(sqlink side)tegmentum/synthetic-mutating-vtab-ducklink-bridge(ducklink side; provides the writer wasm this test loads)Companion PR:
tegmentum/ducklink-extensionfeat/storage-write-dispatch-2.1-- adds the runtime trampolines +storage-write-dispatch@2.0.0WIT on the extension-runtime side that this test exercises.Test plan
tegmentum/synthetic-mutating-vtab-ducklink-bridgeand pointDUCKLINK_WRITER_BRIDGE_WASMat the artifact (or stage it at../../artifacts/extensions/synthetic_mutating_ducklink.wasm).cargo test -p storage-boundary-test --test write_boundary-- confirm all boundary phases (begin, create-table, insert, update, delete, commit, rollback) pass.tests/boundary.rsstill passes (no shared WIT/bindgen regressions).