Added

• PartiQL now works in the browser. The wasm engine serves ExecuteStatement, BatchExecuteStatement and ExecuteTransaction, where it previously answered all three with a 501. Behaviour matches the native build statement for statement, including the RETURNING projections, the per-statement error codes BatchExecuteStatement reports, and ClientRequestToken idempotency on ExecuteTransaction. The engine's advertised capability list grows from 14 operations to 17; CONTRACT_VERSION is unchanged at 1, since adding an operation is additive, so a pinned client keeps working. The engine bundle grows by about 143 KB raw and 53 KB gzipped, which is the parser and executor now being reachable from the wasm entry points.

Changed

• Breaking (Rust API): wasm_api::dispatch and wasm_api::dispatch_http take a DispatchContext, which borrows the idempotency caches a ClientRequestToken needs. Both are behind the wasm-sqlite feature, so a native library consumer is unaffected, and the #[wasm_bindgen] surface the npm package calls (open, execute, dispatchHttp, capabilities, contract_version) is unchanged. Callers of dispatch build a context from the new public TokenCaches. This is separate from CONTRACT_VERSION, which does not move.
• The wasm build's documentation no longer describes it as unverified. The preview label stays, and now rests on what remains unimplemented - TransactWriteItems, streams, tags and TTL - rather than on an absence of test data.

Fixed

• PartiQL SELECT on ExecuteStatement now paginates: NextToken is honoured and returned, and Limit bounds the rows evaluated rather than the rows matched, matching DynamoDB and the existing Query and Scan semantics. A filtered SELECT with a Limit can therefore return fewer rows than before for the identical request, and a page can come back short or empty while still carrying a NextToken, so callers should follow the token rather than treat a short page as the end of the result. A SELECT bound to a partition key now reads in ascending sort-key order, and its sort-key conditions are pushed into the read, so Limit paces against rows in the key-condition range rather than the whole partition; a condition a key condition cannot express falls back to the partition-wide read and filters as before. A NextToken is now rejected when replayed against a different statement or different Parameters, not just a different table, where it previously resumed the walk and silently skipped rows; the mismatch carries DynamoDB's NextToken does not match request message (captured eu-west-2) while an undecodable token keeps Invalid NextToken. Limit: 0 is rejected with the message DynamoDB's ExecuteStatement returns (the Scan-shaped wording, also captured); it previously read nothing and returned no token, making a paginated walk look complete.
• PartiQL SELECT COUNT(*) is removed. It was a dynoxide-only extension: real DynamoDB rejects the projection outright, so a statement that worked locally broke in production. A COUNT(...) projection now returns DynamoDB's exact ValidationException, the bare Unexpected path component message with the 1-based position of the COUNT token (captured eu-west-2), fired before the table-existence check, on ExecuteStatement, BatchExecuteStatement and ExecuteTransaction alike. Note this removes a previously shipped dynoxide feature rather than fixing it in place; there is no replacement, matching DynamoDB, where counting means paging the rows yourself or using Query/Scan with Select: COUNT.
• The wasm engine refuses a CreateTable carrying an enabled StreamSpecification or Tags, and an UpdateTable carrying a StreamSpecification, before creating or changing anything, with the same typed UnsupportedOperation envelope and 501 status the unimplemented operations use. Previously the table was created first and the stream or tag step then failed with a 500, so an AWS SDK retried the error and surfaced ResourceInUseException for the half-created table; the conformance suite's streams probe scored that as a failure where it now correctly records a skip. Every backend capability refusal (BackendError::Unsupported) now maps to this envelope rather than to a 500 InternalServerError, so a client - and an SDK retry policy - can tell a scope gap from a server fault.

Read more

Fixed

• Passing a top-level argument together with a subcommand is now a hard parse error, where the argument was silently ignored. The top-level --host, --port, --db-path and --encryption-key-file exist for the bare pre-subcommand form (dynoxide --port 8000) and only fed the no-subcommand path, so dynoxide --db-path data.db serve started an in-memory server, never created the file, and the data was gone on exit with nothing said about it; dynoxide --port 8893 serve listened on 8000. Combining one with serve, mcp, import or healthcheck now fails up front with clap's conflict error naming the offending option, and the same option after the subcommand keeps working as before (#141).

Security

• On Windows, the HTTP and MCP listeners now bind with SO_EXCLUSIVEADDRUSE, closing a hole where another process running as the same user could take over either port with SO_REUSEADDR while dynoxide was serving. Restarting immediately after a clean shutdown still works; a regression test covers the rebind, and CI now runs the unit tests on Windows (#23).

Fixed

• A CreateTable request whose StreamSpecification sets StreamEnabled: false but also supplies a StreamViewType is now rejected with the ValidationException real DynamoDB returns (One or more parameter values were invalid: Table is being created with a stream disabled, UpdateViewType should not be specified), where dynoxide accepted it. A view type only has meaning when the stream is enabled, so the two cannot be combined at table creation (#115).
• A CreateTable global or local secondary index using ProjectionType: INCLUDE without a NonKeyAttributes list is now rejected with the ValidationException real DynamoDB returns (One or more parameter values were invalid: ProjectionType is INCLUDE, but NonKeyAttributes is not specified), where dynoxide accepted it and created the table. INCLUDE projects the index key attributes plus an explicit list, so the list is mandatory; the shared projection validator now requires it, closing the gap for both index types (#116).
• Query and Scan now return DynamoDB's exact message when Select: SPECIFIC_ATTRIBUTES is given with no ProjectionExpression or AttributesToGet, where dynoxide rejected the request correctly but with its own wording. Both carried the same non-AWS string; the corrected phrase is Must specify the AttributesToGet or ProjectionExpression when choosing to get SPECIFIC_ATTRIBUTES, which Query wraps in the 1 validation error detected: envelope and Scan returns bare, matching real DynamoDB (#121).
• TransactWriteItems now reports top-level ReadCapacityUnits and WriteCapacityUnits in its ConsumedCapacity, where only the nested Table breakdown carried them. A transactional write reports write capacity (a standalone ConditionCheck costs 2 write units on its own table line under INDEXES), and a same-token idempotent replay now reports a recomputed transactional read cost, rounded at 4KB read granularity, rather than re-reporting the first call's write units relabelled as read. The two magnitudes diverge above 1KB (writes round at 1KB, reads at 4KB); for a ~1.5KB item the first call reports 4 write units and the replay 2 read units. The replay honours its own ReturnConsumedCapacity mode. Single-item operations are unchanged. Confirmed against real DynamoDB by the conformance suite.
• A TransactWriteItems call with a ClientRequestToken now holds the idempotency lock across the whole first call, closing a window where two concurrent same-token calls could both execute the transaction. The lock was previously released between the cache check and execution, so racing same-token calls each ran the transaction; the second now waits and replays the first's result. Transactions without a token are unaffected.
• PartiQL ExecuteTransaction now honours ClientRequestToken idempotency, where it ignored the token and re-applied the statements on every call. A same-token, same-statements call within the 600-second window replays the stored result without re-executing (a same-token call with different statements returns IdempotentParameterMismatchException), using the same hold-the-lock-across-execute guard as TransactWriteItems so concurrent same-token calls serialise rather than double-apply. The cache is separate from the TransactWriteItems one, since idempotency is scoped per API operation. ExecuteTransaction also now reports transactional ConsumedCapacity split by statement kind (write capacity for a write set, read capacity for an all-SELECT read set, and read on a replay) at 2 units per statement, replacing a flat 1-unit-per-statement estimate with no read/write split. Confirmed against real DynamoDB by the conformance suite.
• GetItem, Query, Scan, BatchGetItem, and TransactGetItems now reject an invalid ProjectionExpression before any item is read, where dynoxide validated it lazily per row. Overlapping paths (a and a.b), duplicate paths (a and a), and undefined expression-attribute names are rejected with DynamoDB's Invalid ProjectionExpression: messages, so a lookup that matches nothing still rejects rather than returning an empty result. Confirmed against real DynamoDB in eu-west-2.
• A ProjectionExpression selecting several indices of one list now returns them compacted and in ascending index order, where dynoxide returned them in request order: #l[2], #l[0] on [l0, l1, l2] now yields [l0, l2]. Confirmed against real DynamoDB in eu-west-2.
• A ProjectionExpression naming two or more sub-attributes of the same list index now returns them merged into a single list element, where dynoxide split each path into its own element: l[0].a, l[0].b on { l: [ { a, b } ] } returned [ { a }, { b } ] and now returns [ { a, b } ]. The merge holds at depth (nested maps and nested lists under one index), distinct indices still stay separate and compact to ascending order, and the fix reaches every projecting read through the shared reconstruction path (GetItem, Query, Scan, BatchGetItem, TransactGetItems). Confirmed against real DynamoDB in eu-west-2 (#126).
• Query now accepts a KeyConditionExpression sort-key comparison with the value on the left (:lo <= #sk), treating it as the attribute-on-left form (#sk >= :lo) for each of <, <=, >, >=, where dynoxide rejected it. A nested or indexed path on a key attribute is now rejected with DynamoDB's message (Invalid KeyConditionExpression: KeyConditionExpressions cannot have conditions on nested attributes), replacing dynoxide's own wording. Confirmed against real DynamoDB in eu-west-2.
• BatchGetItem now rejects a request that uses an expression ProjectionExpression on one table's block and a non-expression AttributesToGet on another, where dynoxide accepted it. Real DynamoDB rejects the whole request even when each block is internally consistent. Confirmed against real DynamoDB in eu-west-2.
• PutItem and UpdateItem validation ordering now matches real DynamoDB: an empty or invalid TableName is reported on its own, before the Return* enum checks, where dynoxide aggregated them into one envelope. UpdateItem additionally stops at the first invalid enum (reporting ReturnValues), where PutItem continues to aggregate every invalid enum, matching each operation's own behaviour. Confirmed against real DynamoDB in eu-west-2.
• UpdateTable now merges the request's AttributeDefinitions into the table's existing set, where each call replaced the stored list with only the attributes it carried. DynamoDB treats these as a delta: adding a global secondary index only requires the new index's key attributes, so the table keys and prior indexes' attributes need not be re-declared. Adding two GSIs with delta-only attributes therefore dropped the table keys and the first index's attributes from DescribeTable, and a later PutItem failed index-key validation with Index key attribute GSI1PK missing from AttributeDefinitions. The definitions are now unioned by attribute name, preserving those declared earlier; a redeclared attribute keeps its existing type, matching real DynamoDB, which ignores a conflicting type in the delta rather than overwriting or rejecting it. UpdateTable now also keeps AttributeDefinitions equal to exactly the attributes used by the table key schema and the current index key schemas: deleting a GSI prunes its now-orphaned key attributes, and an entry supplied in the delta that is used by no key schema is dropped rather than stored (neither is an error). All verified against AWS in eu-west-2 (#129).

Fixed

• A ConditionExpression comparing a Map (M) or List (L) attribute for equality now works, where = always reported not-equal and <> always equal regardless of the values. compare_values had no arm for document types, so every map or list comparison fell through to the not-equal default; it now compares them deeply - maps order-independently, lists element-wise in order - with nested numbers normalised as elsewhere. The same path backs IN, BETWEEN, and contains over document operands, so those are fixed too (#103).
• ExpressionAttributeValues nested beyond DynamoDB's 32-level document limit are now rejected up front with the same ValidationException AWS returns, where before they were accepted and evaluated. The check runs on every path that takes expression values - PutItem, UpdateItem, DeleteItem, Query, Scan, and TransactWriteItems. The stored-item nesting check was also one level too lenient (it accepted a value AWS rejects) and carried a non-AWS message; both now match DynamoDB's limit and wording, confirmed against real AWS in eu-west-2 (#110).
• Number-set equality in a condition or filter expression now compares at full precision, where it parsed each member to f64 and so reported two sets differing only beyond ~15 significant digits as equal. It now uses the canonical numeric form, matching DynamoDB and the way number-set duplicates are already detected on write; the fix also covers number sets nested inside a map or list (#111).
• A Number with a leading + on the mantissa (+5, +1.5, +1e2) is now accepted and stored normalised (+5 reads back as 5), matching real DynamoDB, where dynoxide rejected it with a ValidationException. The validator was reworked to accept exactly DynamoDB's numeric grammar, which also closes two pre-existing gaps in the same direction: malformed forms such as 1+2, 1.2.3, +e2, and a digitless exponent are now rejected, as is any surrounding or internal whitespace (" 5" was previously trimmed and accepted). The accept and reject boundary was verified against real DynamoDB (#109).

Added

• UpdateTable on the wasm preview engine: add or delete a global secondary index, with existing rows backfilled into a newly added index, and change the simple table settings (provisioned throughput, billing mode, table class, on-demand throughput, deletion protection). A stream-specification change through UpdateTable stays unsupported, since streams remain a preview gap, and a newly added GSI is reported immediately ACTIVE rather than transitioning through CREATING.
• The wasm engine gained an operation-level execute API, and a new npm package, @dynoxide/wasm-engine, that ships it. The Worker answers a small versioned RPC - open, execute, capabilities, contractVersion - with {id, op, payload} in and {id, ok, result|error} out, and a bundled EngineClient owns the round trip so you deal in objects instead of hand-building postMessage envelopes. npm run build:wasm assembles the package: the Worker, the two .wasm, the EngineClient, and a manifest.json stamped with the engine and contract versions. Depend on that built package, not this repo's source. The client checks its CONTRACT_VERSION against the engine on boot and fails loudly if they differ, so a stale embed can't quietly mis-read a newer one. The package ships TypeScript types for the client. Still a preview: the wasm path isn't run against the conformance suite.

Changed

• On the wasm backend, the per-write and per-delete secondary-index fan-out now crosses the JS bridge once per index type rather than once per index operation. Keeping a table's GSIs and LSIs in step with a write is a delete and a re-insert per index, each previously its own bridge crossing; a new exec_script primitive carries the whole ordered batch over in a single crossing, so an indexed PutItem or DeleteItem on a table with K GSIs and L LSIs drops from order K+L crossings to a constant two. Index contents and native behaviour are unchanged (#85).
• The browser backend moved from wa-sqlite to the official @sqlite.org/sqlite-wasm engine, maintained by the SQLite team and versioned to track SQLite releases. The bridge now runs through the sqlite3.oo1 API over the OPFS SAHPool VFS, which keeps the no-COOP/COEP guarantee that motivated the original VFS choice (it needs no SharedArrayBuffer). The open/exec/query/close contract is unchanged, so consumers of @dynoxide/wasm-engine need no code change. A busy database now recovers once the holder releases it rather than staying busy until reload, and the full 64-bit integer round-trip and the fnv1a_hash scalar are re-proven on the new engine (#61). The shipped SQLite .wasm is larger than before (~845 KB against wa-sqlite's ~545 KB).

Fixed

• An empty-binary key value now surfaces as a top-level ValidationException on every path, matching DynamoDB. Previously the lookup path (GetItem/DeleteItem/UpdateItem, batch, and a transact Update/Delete/ConditionCheck Key) returned the older ...were invalid:... wording and, inside a transaction, a ValidationError cancellation reason rather than hoisting; the same cancellation-instead-of-hoist gap also affected an empty-binary table item key and an empty-binary secondary-index key in a transaction. This is the binary counterpart to the empty-string key fix #98; real DynamoDB returns the same top-level ...are not valid. ... empty binary value... messages (table keys, and the put and update forms for secondary-index keys), confirmed identical across four regions.
• Inside a TransactWriteItems, an empty-string value in the lookup Key of an Update, Delete, or ConditionCheck was wrapped in a TransactionCanceledException; it now surfaces as a top-level ValidationException, matching DynamoDB and completing the empty-string key fix #95 made for the Put item key. Wrong-type and non-scalar lookup keys still cancel with a ValidationError reason, and the corrected empty-string message now also matches DynamoDB on the single-action GetItem/DeleteItem/UpdateItem and batch lookup paths (#98).
• BatchWriteItem now reports a wrong-type or non-scalar table key in a put request with DynamoDB's generic The provided key element does not match the schema, rather than borrowing PutItem's Type mismatch for key ... wording. Real DynamoDB collapses both cases to the schema error inside a batch. The empty-string table-key message and the secondary-index key messages already matched and are unchanged, and PutItem and the other put-shaped paths keep the specific type-mismatch message (#97).
• Query and Scan now reject two Select/ProjectionExpression combinations that real DynamoDB rejects before reading any item, where dynoxide previously returned results: a ProjectionExpression with any Select other than SPECIFIC_ATTRIBUTES (such as ALL_ATTRIBUTES), and Select: ALL_PROJECTED_ATTRIBUTES without an IndexName. Both now return a ValidationException with DynamoDB's message (#96).
• Inside a TransactWriteItems, a key (table or secondary index) carrying an empty string was wrapped in a TransactionCanceledException; it now surfaces as a top-level ValidationException, matching DynamoDB. Wrong-type and non-scalar key values still cancel with a ValidationError reason, so only the empty-string case changes. A non-scalar table key no longer fails as an internal error before the transaction runs, and an update that sets a secondary-index key to an empty string now returns DynamoDB's distinct update-path message rather than the put-shaped one (#95).
• A write whose secondary-index (GSI or LSI) key attribute is the wrong type, a non-scalar, or an empty string is now rejected with a ValidationException matching DynamoDB's exact message, where before it was silently accepted (kept out of the index but still written to the base table). Validation runs on every write path - put, update, batch, transactional, PartiQL, and import. An update only re-checks an index key it actually changes, so an unrelated update to a row holding a pre-existing bad value still succeeds (#92).
• A Scan or Query on a composite global secondary index no longer returns items that are missing the index sort key; they are now excluded from the index (sparse-index behaviour), matching DynamoDB. Index membership was gated on the partition key alone, so an item carrying the partition key but no sort key was written into the index at an empty sort-key position. Membership is now a single shared rule across both global and local secondary indexes, applied on every write path - put, update, batch, transactional, PartiQL, import, and GSI backfill - and it also excludes an item whose index key attribute is present but not a scalar. In-memory databases start fresh each run and are unaffected; only a file-backed database, or a snapshot taken from one, written by an older build carries stray index rows. They clear as each affected item is next written, and a persisted store can rebuild an index by dropping and re-adding it (#91).
• PutItem and the other write paths now accept a {"NULL": false} attribute value and read it back as {"NULL": true}, where before they rejected it with One or more parameter values were invalid: Null attribute value types must have the value of true. The NULL member is typed as a plain boolean in the model, so false was valid input all along; AWS has dropped the server-side true-only rule and normalises false to true on read, and dynoxide now matches. A non-boolean NULL such as {"NULL": "no"} is still rejected as a type error (#62).
• Hardened the wasm engine preview ahead of a stable @dynoxide/wasm-engine publish. A body-less operation such as ListTables now round-trips instead of failing as a SerializationException (#65). OPFS open tells a busy database (another tab holding its lock) apart from one that is genuinely unavailable: the busy case surfaces a stable com.dynoxide.wasm#OpfsUnavailable error rather than silently forking to a separate in-memory store, while a private window or quota error still degrades to an ephemeral session. Re-opening opens the new database before closing the old, so a failed re-open leaves the working session intact, and closing a database releases its OPFS handles so the name is free for another tab (#64). The bridge round-trips full 64-bit integers, and a cross-backend test pins the fnv1a_hash scalar the wasm and native backends share (#61). A headless-browser CI job exercises the shipped bundle against the real wasm engine and OPFS on every PR (#68).

Read more

Security

• Close a DNS rebinding vulnerability in the MCP HTTP transport
  (GHSA-fvh2-gm75-j4j7 /
  CVE-2026-42559) by upgrading rmcp
  from 1.1.1 to 1.6.0 in both lockfiles. A malicious page could make the
  user's browser send requests to a loopback MCP server with a non-loopback
  Host header, which the server would then process. Affects 0.9.3 to 0.9.12.
  Users running dynoxide mcp --http or dynoxide serve --mcp should
  upgrade; stdio transport is unaffected.

• Close a related cross-origin CSRF gap: a page could fetch the loopback
  endpoint with mode: 'no-cors', and the Host check would pass while the
  Origin header went unchecked. Affected write tools: put_item,
  update_item, delete_item, create_table, and batch_write_item.
  Fixed by setting an explicit Host and Origin allowlist on
  StreamableHttpServerConfig. Native MCP clients (Claude Code, Cursor,
  the dynoxide CLI) don't send an Origin header and are unaffected.

Fixed

• Unix: port releases immediately after dynoxide serve shuts down. The listener used to skip SO_REUSEADDR, leaving leftover TIME_WAIT sockets from connected clients to block restart for ~60s. Live-listener conflict detection is unaffected: SO_REUSEADDR only bypasses TIME_WAIT, not active sockets.

  Windows: unchanged. SO_REUSEADDR lets another process hijack an active bind there, so we leave it off.