Summary
The NodeDB-Lite WASM array smoke test cannot run to completion on
wasm32-unknown-unknown, because pagedb reads the wall clock through
SystemTime::now(), which panics on that target with "time not implemented on
this platform". The panic happens inside the storage transaction, before the
test reaches any engine code.
Evidence
nodedb-lite-wasm/tests/array.rs::create_put_slice_roundtrip, run under the
Node wasm-bindgen runner with full symbols (--profile debugging):
panicked at library/std/src/sys/time/unsupported.rs:35:9:
time not implemented on this platform
at <std::time::SystemTime>::now
at pagedb::txn::write::commit::<impl WriteTxn<V>>::commit_body::{{closure}}
Reproduced against nodedb-lite @ 59dad1c, with the shared nodedb-* crates
patched to a local nodedb worktree so the array HLC routes through the
target-split clock helper. The blame frame is pagedb::txn::write, not the
array engine — the array's own clock call is js_sys::Date::now() on that
target and is not in the stack.
Why it matters beyond one test
pagedb is the storage layer under every Lite WASM build, so any wasm code path
that commits a write transaction reaches this. It also blocks the only existing
runtime coverage for the shared crates' browser clock: array.rs is the test
that exercised the array HLC that panicked in the first place, so while pagedb
reads SystemTime::now() directly, that coverage cannot be restored.
Suggested direction
The same target split the shared crates use: js_sys::Date::now() on
wasm32-unknown-unknown, std elsewhere. nodedb-types::clock::since_epoch()
now exists for exactly this and is the helper the shared crates route through,
though pagedb is a separately published crate and may prefer its own.
Environment
wasm32-unknown-unknown, Node 22 via wasm-bindgen-test-runnernodedb-lite @ 59dad1c, nodedb shared crates @ local worktree- run:
CARGO_TARGET_WASM32_UNKNOWN_UNKNOWN_RUNNER=wasm-bindgen-test-runner cargo test --profile debugging -p nodedb-lite-wasm --target wasm32-unknown-unknown --test array
Summary
The NodeDB-Lite WASM array smoke test cannot run to completion on
wasm32-unknown-unknown, becausepagedbreads the wall clock throughSystemTime::now(), which panics on that target with "time not implemented onthis platform". The panic happens inside the storage transaction, before the
test reaches any engine code.
Evidence
nodedb-lite-wasm/tests/array.rs::create_put_slice_roundtrip, run under theNode wasm-bindgen runner with full symbols (
--profile debugging):Reproduced against
nodedb-lite@59dad1c, with the sharednodedb-*cratespatched to a local
nodedbworktree so the array HLC routes through thetarget-split clock helper. The blame frame is
pagedb::txn::write, not thearray engine — the array's own clock call is
js_sys::Date::now()on thattarget and is not in the stack.
Why it matters beyond one test
pagedbis the storage layer under every Lite WASM build, so any wasm code paththat commits a write transaction reaches this. It also blocks the only existing
runtime coverage for the shared crates' browser clock:
array.rsis the testthat exercised the array HLC that panicked in the first place, so while
pagedbreads
SystemTime::now()directly, that coverage cannot be restored.Suggested direction
The same target split the shared crates use:
js_sys::Date::now()onwasm32-unknown-unknown, std elsewhere.nodedb-types::clock::since_epoch()now exists for exactly this and is the helper the shared crates route through,
though
pagedbis a separately published crate and may prefer its own.Environment
wasm32-unknown-unknown, Node 22 viawasm-bindgen-test-runnernodedb-lite@59dad1c,nodedbshared crates @ local worktreeCARGO_TARGET_WASM32_UNKNOWN_UNKNOWN_RUNNER=wasm-bindgen-test-runner cargo test --profile debugging -p nodedb-lite-wasm --target wasm32-unknown-unknown --test array