You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(stack): preserve non-Error rejection detail on the wasm-inline entry
`withResult`'s default `ensureError` REPLACES any non-Error throw with
`new Error('Something went wrong')`, discarding the original value
(@byteslice/result@0.2.0, dist/result.js:27). But that is only the
FALLBACK — the library prefers an `onException` hook:
const error = hooks?.onException?.(ex) ?? ensureError(ex)
Nothing in this repo passes it. On the native entry that rarely bites,
because the FFI throws real `ProtectError` instances. On WASM it is a
live hazard: wasm-bindgen rejects with the raw `JsValue` the Rust side
produced (`throw takeFromExternrefTable0(...)` in the generated glue),
and the WASM build exports no `ProtectError` class at all — so a genuine
FFI failure can arrive as a bare string or object.
That made the Result conversion in the previous commit a partial
REGRESSION: the old throwing behaviour at least propagated the raw value
to the caller, whereas `withResult` was silently swallowing it. Fixed by
supplying `onException`.
The six call sites now go through one `wasmResult()` seam that binds both
the failure shape and the hook, so a method added later cannot omit
either — an omission would not fail a build, it would just quietly
degrade failure messages, which is the whole bug.
`toError` preserves strings as-is, JSON-serializes objects (so
`{code, detail}` survives rather than becoming "[object Object]"), and
falls back to `String()` for cycles and other unserializable values.
+2 tests covering string and object preservation, plus the cyclic
fallback. 833 pass; 0 biome errors; zero new tsc errors (diffed against
main's error set, not counted).
0 commit comments