DX3: transactions, TypeScript, and the quality apparatus

[tamnd]

Milestone DX3 of the developer-experience program (Spec/2064g/dx/00-overview.md). Specs: dx/05, dx/06, dx/01 §5, §6, dx/15 §4, §6. Runs with M3 (#4, closed).

TypeScript, the rest of Python, and the apparatus that keeps eleven SDKs from quietly diverging. The scorecard and the misuse suites are not overhead here; they are the only thing that makes a tier claim mean something, and dx/01 §5 now requires a named maintainer per SDK because that is what DuckDB publishes and a tier with no name attached is a commitment nobody made.

The TypeScript surface has one correction from the 2026 audit (AUDIT-2026-08.md §2.3). Temporal reached Stage 4 in March 2026 but is unflagged only in Node 26, Chrome/Edge 144, and Firefox 139; Node 24 is the current LTS and needs a flag, and Safari is still behind one. So the stable public types are ZuDate/ZuTimestamp/ZuDuration with toTemporal(), and { temporal: true } opts into Temporal directly and throws at connect time if the runtime lacks it, rather than returning undefined three frames later.

C ABI (dx/02 §3):

• transactions, appender, diagnostics on the ABI

TypeScript SDK v1 (dx/05):

• napi-rs 3, platform packages under optionalDependencies, no postinstall script, no node-gyp
• await using / AsyncDisposable, AsyncIterable, Web Streams, AbortSignal to zu_conn_interrupt
• INT64 is bigint by default, bigIntMode: "number" documented with its hazard and never the default
• ZuDate/ZuTimestamp/ZuDuration value objects, { temporal: true } opt-in
• dual ESM/CJS, types first in every export condition, no default export
• Node 24 and 26, Bun 1.3, Deno 2.9 all in CI as first-class targets

Python SDK v1 (dx/06):

• transactions, register() replacement scans, zudb.aio
• notebook rendering: _repr_html_ for results, nodes, rels, paths; %%gql magic
• DB-API 2.0 layer at zudb.dbapi

quality apparatus:

• scorecard tooling with the maintainer and repository fields, published to /docs/clients/overview (dx/01 §5)
• misuse and lifecycle suites per SDK, plus sanitizer and leak jobs (dx/15 §4)
• API stability gates wired in: cargo semver-checks, griffe check, api-extractor (dx/15 §6)
• clean-machine install test per SDK, nightly, in a container with only the language runtime

measured against DuckDB (docs/clients/duckdb.md, #383):

• a columnar result: the executor keeps its vectors, QueryResult owns them, and Vec<Vec<Value>> becomes a gather the row path does rather than a transpose every other path undoes
  • the transpose happens once, in the engine, in zu::query::column (Read a result down its columns, once, in the engine #388)
  • the sink keeps the vectors, so there is no transpose left to do (Keep the vectors in the sink #421)
• Arrow export as a handoff: to_arrow, __arrow_c_stream__ and record_batches describe buffers and a release callback, no copy for the six physical types whose layout is already Arrow's (zu-python#23, and the Node half is the row below)
  • one translation, in the engine tree, so a column cannot mean one thing in Python and another in Node (One translation into Arrow, in the engine #423)
  • the Node half: conn.arrow() and prepared.arrow(), IPC bytes because a JavaScript runtime cannot read a pointer (zu-node#24)
  • the Python half: the seven hundred lines here deleted, record_batches(rows_per_batch) added the way DuckDB spells it (zu-python#31)
• the TypeScript client reaches the Python one: transactions, appender, register, bulk load, columnar read
• prepared statements, explain and profile in both clients, which is what the api-map scorecard item is blocked on (zu-node#19, zu-python#25)
• real streaming: a result read a chunk at a time as the executor produces it, not a slice of a result that is already whole (zu-node had it, zu-python#26)
• the small ones
  • an in-memory connection that does not make a file, in the engine rather than in each client (A database that never touches the filesystem #405, zu-python#27, zu-node#20)
  • cursor() in both, which is how a pool is written (A second connection made from the first #409, Say that a pool has what it needs now #413, zu-python#28, zu-node#21)
  • fetchmany for the DB-API, and on the result under it (The fetch row is done #415, zu-python#29)
  • fetchnumpy, the engine's own buffers moved into numpy (The frames row is done #417, zu-python#30)
  • a progress callback in Node, over a rowsRead the engine was already counting (The progress row is done #418, zu-node#22)

done when:

• three SDKs at tier-1 scorecard thresholds
• the differential suite shows zero divergences across Rust, Python, and TypeScript on the full corpus
• installs verified on clean containers for all three

[tamnd]

The C ABI line is done. Three pull requests, one per third: transactions in #322, the appender in #323, and diagnostics in #327.

Transactions are zu_begin, zu_commit, zu_rollback and zu_conn_in_transaction. The first three run the statements START TRANSACTION, COMMIT and ROLLBACK rather than reaching past the parser, so a host that sends the words and a host that calls gets the same session state and the same conditions, and a binding wrapping this in a block, a using or a defer gets a signature instead of a string to build. Beginning inside one is 25G01 rather than a nesting this engine does not have, ending nothing is 2D000 rather than a call that quietly did nothing, and a read only transaction is enforced at the statement that wrote rather than at the commit, so the host is told which statement was the one it should not have sent. zu_conn_in_transaction is there because it is the one thing about a transaction no statement answers and every cleanup path needs it. Closing a connection with one running rolls it back.

The appender is zu_appender_open, the zu_append_* value calls, zu_append_end_row, zu_appender_flush, zu_appender_discard, zu_appender_close and zu_appender_free. It is the half of loading zu_loader_create does not cover: the loader builds a database that is not there yet, this adds to a table that is. A row written as a statement is parsed, bound, planned and committed, and the commit is the expensive part, so a million rows that way is a million syncs nobody asked for; an appender buffers and pays one commit per flush. The column is a position rather than a name, because a lookup per value is a cost on the one path where per-value cost is the whole story. A refused value ends its row and takes back what that row had already written, so what the loop writes next is a row rather than the tail of a broken one, and the error names the column rather than leaving a host to work out which of five it was. A rel table's two columns are the two ends of an edge, and an edge to a row that is not there is refused at the flush before anything is written.

Diagnostics are zu_result_gqlstatus, zu_result_notices and zu_result_notice, which is the half of the GQLSTATUS envelope a host reading rows and errors could not see. The status a call returns says whether a statement worked; the completion condition says which way, 00000 for one that answered with columns and 00001 for one with no projection to give back, and that is the value the JSON Lines protocol already writes into every record and a conformance harness already grades. The notices are the conditions a statement raised and carried on through: an exception replaces a result and arrives as an error, a warning rides along with one, because a statement that dropped a null out of an aggregate still has rows to give you. A notice comes back as a zu_error rather than as a second shape, since the code, the standard text, the severity, the place and the doc page are the same accessors either way and zu_error_severity is what tells the two apart, and it is a copy rather than a borrow so the rule for every zu_error a host is handed stays the one rule: free it.

The header is the specification and is committed rather than generated, so all three landed as prose in zu.h first and code second, and cargo xtask package gates that the two agree in both directions, that the declared list is sorted, and that the revision in the header matches the one in the crate. It is 0.10 now, from 0.7 before this work, and every step was additive. The surface is 115 functions.

Each third has its tests in crates/zu-capi/tests/capi.rs, which is 43 tests over raw pointers and nothing reaching into the Rust types behind them, and its block in crates/zu-capi/tests/smoke.c, which links the shared library the release ships with a compiler that is not rustc and runs under both sanitizers and Valgrind in CI. That second one is what catches a symbol that was not exported and a header that disagrees with the library about a layout, which the Rust test cannot see because it links the rlib. docs/10-api-and-tooling.md has a paragraph on each.

Next is the TypeScript SDK.

[tamnd]

The JavaScript client has its first working piece: tamnd/zu-node#1, merged.

connect, query, exec, close and await using, named parameters both ways, every value the engine has including nodes, rels, paths and the four temporal classes, and the whole error surface. The binding is napi-rs 3 against the engine crates rather than the C ABI, which is ADR 0002. Every call is a task on libuv's threadpool, so nothing can block the event loop, and a connection sits behind a mutex so that a program which shares one by accident waits rather than corrupts.

Two decisions came out of building it that are worth writing down here. A result is an array of row objects with columns, gqlstatus and notices beside the elements as properties that are not enumerable, so iterating it is for...of and nothing else while the same value still spreads, stringifies and deep-equals the plain array it is. And every refusal is a rejection of the promise the call already returned, including a closed connection and a parameter of a type nothing can bind, so one await catches everything one statement can do rather than a caller needing a try around the call and a catch around the promise.

Thirty four tests, green on Node 24, and CI runs fmt, clippy and the suite on Node 24 and 26 across Linux, macOS and Windows. There is a benchmark that measures what the client adds to the engine rather than the engine itself, by comparing a scan against the same scan with the rows dropped: on my machine the boundary costs about 400 ns per row of two columns.

No box above is ticked yet, because each of those lines is wider than what landed. Line one wants platform packages under optionalDependencies and there are no prebuilt binaries yet. Line two has await using and wants AsyncIterable, Web Streams and AbortSignal. Line three has INT64 as bigint and wants bigIntMode documented with its hazard. Line four has the four value classes and wants toTemporal() and the { temporal: true } opt-in. Those are the next pull requests, in that order, each with its own tests.

Two engine notes from writing the tests. CREATE NODE TABLE is not implemented, so a table is declared by its first insert and that one has to be written with literals, since the engine works out what each column holds from the values it was given. And a read-only connection does not see writes that live only in the .wal, so no test depends on that.

[tamnd]

Packaging is done, in tamnd/zu-node#2. npm i zudb is now a download of one file for the machine doing the installing: the root package carries the loader and no binary, each of eight platforms has its own package holding exactly one addon, and npm picks the one that fits out of optionalDependencies by os, cpu and libc. No postinstall, no node-gyp, no compiler, and no fetch from anywhere but the registry.

The eight are the tier 1 rows of platforms.toml plus Windows on arm64, which is tier 2 there and cheap here because the runner exists. The list lives in one file, tools/platforms.mjs, and the release workflow builds it, the test suite holds package.json and the npm/ directories to it, and tools/packages.mjs checks the whole set before anything is published. The glibc rows build inside manylinux_2_28, so the floor is the same glibc 2.28 the engine promises, and the musl rows build inside Alpine 3.24 through docker rather than as a job container, because GitHub runs the JavaScript half of an action inside the job's container and has no Alpine build of it for arm64.

Two things came out of it that are worth writing down for the other SDKs.

The optional dependencies cannot be checked in. Naming the eight packages in package.json is the obvious way to say what an install resolves, and it is also a lock file npm cannot complete: a package that has not been published yet resolves to nothing, npm install records the range and no entry, and every npm ci after that fails with "missing from lock file" on all eight. napi pre-publish writes the block from napi.targets at the version being released, which is where it belongs, and there is a test that keeps it out of the manifest along with the reason it has to stay out.

The arm64 musl row needs its linker named, and named in the right place. Rust's aarch64 musl target asks for aarch64-linux-musl-gcc, which is what a cross toolchain calls its compiler and not what a machine compiling for itself has, so the build stops at the first proc macro. Putting -C linker=gcc in RUSTFLAGS does nothing, because cargo stops applying RUSTFLAGS to host artifacts as soon as a target is named and napi always names one, and the proc macro build scripts are exactly those host artifacts. CARGO_TARGET_AARCH64_UNKNOWN_LINUX_MUSL_LINKER=gcc applies to every unit built for that triple and fixes it. The x86_64 musl target asks for cc and finds it, which is why seven of the eight rows were green while that one was red.

What is checked, beyond the eight builds. Five tests over the manifests: no install-time script and no gyp-shaped dependency, files is four files and no binary, the targets and the directories and the loader's requires all agree, every platform package says which machine it is for and holds one file, and one built addon sits beside the loader. Then tools/binary.mjs fails the build row that produced a file named after a different target, and tools/install.mjs packs the two tarballs npm would fetch, installs them into an empty project outside the checkout, and runs a statement through what came out. That last one is the only thing covering the case where seven of the eight optional dependencies cannot be fetched, which is every install today, and it is also the beginning of the clean-machine install test that line four of the quality apparatus asks for. That line stays unticked: it wants a nightly run in a container carrying only the language runtime, per SDK, and this is one runner with a full toolchain on it.

The release run on the pull request built all eight, laid them into their packages, wrote the optional dependencies, and installed the result. The tag path is wired but not taken: nothing is published, and the publish job is the only one that reads the npm token.

[tamnd]

AbortSignal is in, as tamnd/zu-node#3. The line it belongs to stays unticked because two of its four things are left: await using landed with the first PR, the signal landed with this one, and AsyncIterable and Web Streams are next.

Every statement takes a third argument now, and what is in it today is a signal:

const rows = await conn.query(statement, params, { signal: AbortSignal.timeout(50) });

It is the signal JavaScript already has, so a timeout written like that, the signal a framework hands a request handler, and an AbortSignal.any([...]) composed out of both all work without anything being adapted. When it fires, the connection's interrupt is raised and the executor notices it at a boundary it was already stopping at: measured on the statement the tests use, an abort comes back three to eight milliseconds after it was asked for, against six hundred for the same statement run to the end. The promise rejects with the signal's own reason, which is what fetch does, so a caller who already wrote catch around a timeout gets their own object back rather than a GQLSTATUS to translate.

Two things about the engine were worth writing down while doing it.

The interrupt belongs to the connection rather than to the statement. Session arms one handle when it is built and nothing in the engine ever clears it, so a stop raised a moment after a statement finished is a stop that ends the next statement on that connection. Every client that wires cancellation to Interrupt::stop has to clear it as the statement leaves, or it will ship this bug. The client does that under a flag the listener reads before it raises anything, and a test asserts the statement after an aborted one answers normally. It is worth asking whether the engine should clear the interrupt itself when a statement completes, since every binding needs the same thing and the one that forgets fails in a way that looks like a flaky test.

Where the executor checks the interrupt matters more than how often. A cross product aggregated with count stops within milliseconds. The same cross product with ORDER BY x LIMIT 1 over three hundred rows does not stop at all until it is finished, which reads as a sort phase that never checks, and a caller who set a timeout on a sorting statement will not get it. Not a blocker for this client, since the statement still ends and the connection is left clean, but it is the kind of gap a timeout is bought to close.

Also, a signal that never fires costs about two microseconds a statement, against nine for the promise and the threadpool round trip that carry the cheapest statement there is. npm run bench has a row for it now.

[tamnd]

Dual ESM and CJS is done, in tamnd/zu-node#4.

The generated binding is now binding.cjs with binding.d.cts beside it, and the package proper is four files over the top of it: zudb.cjs requires the binding and names every export one at a time, zudb.mjs reaches those same objects through createRequire, and the two declaration files say the shape to a resolver that reads .d.cts for require and .d.mts for import. One load underneath both, so a ZuDate made through import is an instance of the ZuDate reached through require. That matters more than it sounds: two separate loads would give a program with a mixed dependency tree two of every class, and instanceof would start answering no for reasons nobody could see. There is no default export in either format.

types is the first key in both conditions, which is the whole of the line and also the part that has no symptom locally. Conditions match in the order they are written, so a types written after default is a types no resolver ever reaches, and the package type-checks in its own checkout and is any in every consumer.

Three things now check the package as a resolver sees it rather than as the checkout sees it. npm run check:types compiles a .mts and a .cts program against the published shape under node16, npm run check:package runs attw --pack . and reports no problems for node10, node16 CJS, node16 ESM and bundler, and the export test writes out the eleven names rather than deriving them from either format, since a name that goes missing from both at once is what a derived list cannot see. The tests import 'zudb' now instead of a relative path, so every one of them resolves through the package's own exports map. Both checks are a CI job, and the install round trip runs a statement through require as well as through import inside the installed project.

One addition to the surface came out of this: isZuError. A catch clause holds an unknown, and there was no way to ask whether the thing caught was a zu failure without reading the name off it and hoping. It answers no for a plain Error, a string, null, and an AbortError, which is the one a caller most needs kept apart from the database's own conditions, and in TypeScript it narrows to the full error shape.

Left on this milestone's TypeScript lines: AsyncIterable and Web Streams over query_stream, bigIntMode, toTemporal() and { temporal: true }, and Bun and Deno in CI.

[tamnd]

Streaming is done, in tamnd/zu-node#5, with one engine fix underneath it in #338.

conn.stream(...) gives a ZuStream, and there are three ways to read it, all of them the same statement. for await (const row of stream) is a row at a time, stream.batches() is the shape the rows actually cross the boundary in, and toReadableStream() is a Web Stream for the code that wants to pipe. Ending the loop early ends the statement: a break, a throw, an await using block closing, a reader.cancel() and an explicit stream.cancel() all arrive at the same finally, which stops the statement and waits for it to let go of the connection before returning. That wait is the part worth having, because without it the next statement on that connection queues behind a scan nobody is reading.

Under the JavaScript is a ZuCursor, which is a pull: one call, one batch, null at the end. The statement runs on its own thread and hands batches through a bounded queue of two, so a reader that stops reading stops the scan rather than filling memory with rows it will never look at. The statement does not start until the first read, which is why a syntax error from conn.stream('MATCH (') arrives at the first await in the loop rather than at the call, where a caller has no catch around it. Iteration, early exit and Web Streams are written in JavaScript over that cursor rather than in Rust, because they are JavaScript shapes and the native version of a for await that breaks halfway is a great deal of machinery for something the language already does.

The summary carries streamed beside columns, rows, stopped and notices, and it is there because of something the tests found. A statement that has to see every row before it can give one, which is ORDER BY, DISTINCT, the aggregates and anything that writes, is not a plan the pipeline executor takes, so the engine runs it whole and hands the result over in batches afterwards. The loop reads identically either way, and the first attempt at a backpressure test picked one of those plans and failed for a reason that had nothing to do with the client. Rather than leave that difference invisible, the summary now says which of the two happened, and a caller measuring where the time went can tell. batchRows is documented the same way, as a ceiling and not a promise, since batches are cut out of rows that have already been made and a size above the engine's vector gets the vector.

The engine fix is the one real bug this line turned up. A signal fired partway through a scan of sixty thousand rows ended the stream cleanly after exactly 1024, reporting stopped: false, which is to say it reported a truncated answer as a whole one. run_streamed broke out of its morsel loop on stop.stopped(), and that is true both for a quota that has been filled and for a caller who interrupted, so the two ended a run the same way when they mean opposite things. The loop now checks the interrupt before that break, so an interrupted statement raises rather than returning. The test for it runs under both executors and needs more than 1024 rows to be worth anything, because morsels have a floor of that size and a smaller seed leaves one morsel and nothing to interrupt between.

Seventeen tests cover it, including the ones that matter most: a stopped stream leaves the connection usable, eight streams over one AbortController leave no listener behind, a signal that has already fired stops the statement before the engine sees it, an aborted stream rejects with the caller's own reason the way fetch does, and batchRows of 0, -1, 1.5 or a string is refused as a usage error. That last one had a real bug in it: get_uint32 applies JavaScript's own narrowing, so -1 was arriving as four billion and 1.5 as 1. It reads a double and checks it now.

The numbers, on 50k rows, fastest of nine runs. A whole scan of two columns is 372 ns per row and streaming the same two columns is 463, so the row at a time path costs about a quarter more than buffering the lot. Reading a batch at a time is 320 ns per row, which is faster than the whole scan, since nothing builds an array of every row. The first batch of that scan arrives in 1.11 ms against 18.60 ms for the whole thing, which is the point of the exercise stated as a measurement rather than as a claim.

Left on this milestone's TypeScript lines: bigIntMode, toTemporal() and { temporal: true }, and Node 24 and 26, Bun and Deno in CI.

[tamnd]

bigIntMode is done, in tamnd/zu-node#6.

It goes on a statement or on a connection, and a statement on a connection that named one may still name the other. That last part is what makes it usable: the reason a program wants numbers is usually one query whose rows are about to be serialized, and needing a second connection for the one aggregate that counts something large would be a worse API than no option at all.

The default does not move and was never in question. INT64 is bigint, because zu's integers go to 2^63 and a JavaScript number stops telling one integer from the next at 2^53.

The part worth deciding was what happens to the integer that does not fit. Rounding it is what most clients do, and it is the thing this whole rule exists to prevent, so this one refuses the row instead: an integer past 2^53 raises a ZuUsageError naming the column and the value. A caller then knows which column to widen and by how much, rather than reading an id that is off by one and finding out a year later. The hazard that remains is real and is written into the type, the README and the doc comment rather than left to be discovered. Which integers a database holds is a property of the data and not of the program, so a query that returned numbers for every row of a test database can meet a larger one in production, and the failure arrives at read time on a machine that is not yours. That is why it is an opt-in.

The mode reaches the INT64 columns of a result and nothing else. A node's offset, an edge's src, dst and ord, and the nanosecond counts on the temporal classes stay bigint in both modes, because they are properties of classes the addon registers once rather than values a statement can respell. It is a real edge, so it is documented and there is a test holding it in place.

Two things came out of the implementation. The table names a result carries and the spelling of its integers are now one value settled where the connection is held, so the streamed path and the whole-result path read the mode from the same place and cannot drift. And the mode is parsed before the database is opened, so a typo in the connect options does not leave behind a database nobody asked for, which has a test of its own.

Ten new tests, seventy-nine in the suite, tsc and attw clean on all four resolutions, and the install round trip still runs a statement out of the packed tarballs in both formats. On 50k rows one INT64 column costs about 190ns a row as numbers against about 220ns as bigints, which is the small part of why anybody asks for it.

Left on this milestone's TypeScript lines: toTemporal() and { temporal: true }, and Node 24 and 26, Bun and Deno in CI.

[tamnd]

Temporal landed, tamnd/zu-node#7.

{ temporal: true } on a connection gives Temporal values instead of the four classes: a DATE becomes a PlainDate, a local TIME a PlainTime, a local TIMESTAMP a PlainDateTime, a zoned TIMESTAMP a ZonedDateTime at the offset it was written at, and a DURATION a Duration counting months or seconds and nanoseconds. toTemporal() on each of the four classes converts one value on any connection, which is what a program that cannot be sure of its runtime uses.

A time carrying an offset is the one value zu holds that Temporal has no type for, since a PlainTime is local and would drop the offset and a ZonedDateTime carries a date nobody wrote. It stays a ZuTime in temporal mode and everything else in the same row still arrives converted, and toTemporal() on one says why rather than inventing an answer.

The opt-in is a connect option and not a statement one, unlike bigIntMode. Both spellings are exact and neither loses anything, so which one a program wants is a property of the program rather than of the query, where the bigIntMode trade is one a single statement can sensibly make.

Going the other way needs no opt-in. A Temporal value binds as a parameter on every connection, recognized by Symbol.toStringTag, which is one property read for all eight of its classes where instanceof would be one call each. A PlainYearMonth, a PlainMonthDay, a non-ISO calendar and a Duration counting both months and days are refused by name, the last because no number of days is a month and a value holding both would have to invent an answer for one month after 31 January.

The refusal the issue asks for is at the connect and before the file is opened, so a program that asked a runtime for what it does not have fails at the line that asked and leaves nothing on disk, which a test pins with the file's absence. The check has to be read on the runtime's own thread, since that is the only thread that may touch a JavaScript value, so it is read in the call and carried into the task.

The TypeScript types ask globalThis whether the compiler has heard of Temporal rather than importing it, because which lib declares it is different in every version of TypeScript that has shipped since Stage 4. A program with it is checked against the real types, one without gets unknown for a return type and nothing at all for a union member, so ZuValue and ZuParam still narrow exactly as they did.

On 50k rows a DATE column costs about 560ns a row as a ZuDate and about 650ns as a Temporal.PlainDate, against 240ns for the INT64 column beside it. Nothing is cached between rows, because neither a Temporal value nor the constructor that makes one can be held by a struct that crosses to the threadpool thread. The day count becomes a date through Hinnant's civil algorithms, which have no table behind them and round trip over two million days in the unit tests.

Eleven new tests that adapt to the runtime rather than being skipped by hand, so the suite is 90 tests green both with and without the flag. CI runs npm run test:temporal beside the plain suite on Node 24, and Node 26 has Temporal unflagged so the ordinary run there is already the one with it.

Left on this milestone's TypeScript lines: Bun 1.3 and Deno 2.9 in CI as first-class targets, which is the last one.

[tamnd]

Bun and Deno are in CI, tamnd/zu-node#8, which is the last of this milestone's TypeScript lines.

One binary already served all three runtimes, since N-API is the ABI all three implement, and the runtimes table has claimed all three since the first commit. Only Node ran anything, which makes a table like that a promise rather than a fact. The whole suite now runs on Bun 1.3 and Deno 2.9 beside Node 24 and 26, and both of them found something on the first run.

Bun found a native error carrying no stack at all. V8 writes one when the error is made, JavaScriptCore writes none through N-API, so err.stack was undefined there and every logger reaching for it printed that word instead of the failure. What V8 writes for an error made under a running statement is the header line and no frames, since there are no JavaScript frames beneath a native call that is already running, so that line is what the client writes when it finds none. Defined rather than assigned, because the one V8 writes is not enumerable, and a plain assignment put stack into Object.keys(err) on Bun and nowhere else. The test that walks an error's own keys is what caught that, which is the second thing the job found before it went green.

Deno needed --allow-read --allow-write --allow-env --allow-ffi and nothing more, so that is the list the job and the README both carry now, rather than a -A that proves nothing about what a user has to write. It also needs --no-check, which is about the checkout and not about the package: the tests reach the declarations by relative path here rather than through npm:zudb, and Deno reads the .cjs beside them as a module with an export = in it. The package job is what checks the types, through the resolution a user actually gets, and it is untouched.

Deno 2.9 has Temporal unflagged, so the temporal tests run there without anything being asked for. Bun 1.3 does not have it yet and skips those two, the same way an unflagged Node does.

That is the TypeScript SDK v1 list done: napi-rs 3 and the platform packages, await using and the streams and AbortSignal, bigint by default with the hazard of the other mode written down, the temporal values with their opt-in, dual ESM and CJS with types first in every condition, and four runtimes each running the whole suite. Next on this milestone is the rest of Python: transactions, register() replacement scans and zudb.aio, then the notebook rendering, then the DB-API 2.0 layer.