---
title: "Dynoxide 0.11.1: four conformance fixes - Martin Hicks"
description: "Dynoxide 0.11.1 is a small patch: four fixes where the engine evaluated a condition expression or validated a number differently from real DynamoDB - map and list equality, the 32-level nesting limit, number-set precision, and a leading-plus on numbers."
canonical: https://martinhicks.dev/articles/dynoxide-0111-conformance-fixes
last-updated: 2026-07-01
---

![The Dynoxide hexagonal logo centred on a near-black background](https://martinhicks.dev/images/articles/dynoxide-0111-conformance-fixes.png)26th June 2026

# Dynoxide 0.11.1: four conformance fixes

[Dynoxide](https://dynoxide.dev) 0.11.1 is a small patch. Four fixes, all the same shape: spots where the engine evaluated a condition expression or validated a number slightly differently from real DynamoDB. No new features - just drift the [conformance suite](https://martinhicks.dev/articles/dynoxide-conformance-suite) turned up, most of it checked back against real AWS before I closed it.

-   **Map and list equality in a `ConditionExpression`.** Comparing an `M` or `L` attribute with `=` always reported not-equal, and `<>` always equal, whatever the values held. There was no comparison arm for document types, so they fell through to the not-equal default. They now compare deeply - maps order-independently, lists element-wise in order. `IN`, `BETWEEN` and `contains` over documents ran the same path, so they're fixed too. ([#103](https://github.com/nubo-db/dynoxide/issues/103))
-   **Nesting past the 32-level limit.** Expression values nested deeper than DynamoDB's 32 levels were accepted and evaluated; they're now rejected up front with the `ValidationException` AWS returns, on every path that takes expression values - PutItem, UpdateItem, DeleteItem, Query, Scan, TransactWriteItems. The stored-item check was a level too lenient as well, and carried a non-AWS message - both now match, confirmed against eu-west-2. ([#110](https://github.com/nubo-db/dynoxide/issues/110))
-   **Number-set equality at full precision.** Set comparison parsed each member to an `f64`, so two sets that differed only past ~15 significant digits read as equal. It now uses the canonical numeric form, the same way duplicate members are already caught on write, and covers number sets nested inside a map or list. ([#111](https://github.com/nubo-db/dynoxide/issues/111))
-   **A leading `+` on numbers.** Real DynamoDB accepts `+5`, `+1.5` and `+1e2` and stores them normalised (`+5` reads back as `5`); dynoxide was rejecting them. The validator now takes exactly DynamoDB's numeric grammar, which also tightened a few forms that used to slip through the other way - `1+2`, `1.2.3`, a digitless exponent, and stray whitespace like `" 5"`. ([#109](https://github.com/nubo-db/dynoxide/issues/109))

The release is [on GitHub](https://github.com/nubo-db/dynoxide). If you hit something that doesn't match DynamoDB, that's a bug report worth filing - it's exactly what the suite is there to catch.

## Further reading

-    [Dynoxide 0.11.0: wasm on npm, plus a stack of fixes
    
    Dynoxide 0.11.0 ships the browser engine as an npm package, @dynoxide/wasm-engine, and lands a stack of correctness fixes: secondary-index validation on write, sparse-index behaviour, and error messages brought back in line with real DynamoDB.](https://martinhicks.dev/articles/dynoxide-0110-wasm-on-npm)
-    [Building a DynamoDB conformance suite
    
    How I built a 526-test DynamoDB conformance suite, and what it found in DynamoDB Local, LocalStack, Dynalite, and Dynoxide.](https://martinhicks.dev/articles/dynoxide-conformance-suite)
-    [I watched DynamoDB change under my conformance suite
    
    My DynamoDB conformance suite went red and the test that failed was real AWS. It had reworded its validation errors, and the change hasn't reached every region yet.](https://martinhicks.dev/articles/dynamodb-changed-its-validation-errors)

---

Source: https://martinhicks.dev/articles/dynoxide-0111-conformance-fixes