neon-bindings/neon · error

Failed to downcast Any

Error message

Failed to downcast Any

What it means

In `JsBox::from_local`, the external data was successfully unwrapped to a `&Box<dyn Any>`, but `downcast_ref::<T>()` returned None: the boxed Rust value's concrete type is not `T`. The handle IS a Neon JsBox, but of a different inner type, and reconstructing it as `JsBox<T>` would be unsound, so it panics instead.

Solutions

1. Use the exact same T that was passed to `JsBox::new` when converting the handle
2. Use `JsBox::downcast` which returns Option<Self> for safe fallible conversion
3. Reload the addon so stale JS-held handles from a previous binary are not mixed with new types
4. Add a type tag or discriminant in the boxed value if multiple boxed types must be distinguished at runtime

Example fix

Request the correct JsBox<T> matching the type originally boxed with `JsBox::new`, or use `downcast` (returns Option) and handle the mismatch gracefully instead of from_local.

When it happens

Trigger: `from_local::<T>` panics when the `Box<dyn Any>` stored in the napi_external cannot be downcast to `T` — a JsBox of type U is treated as JsBox<T> (type confusion between two boxed Rust types).

Common situations: Casting a `JsBox<UserRecord>` to `JsBox<OtherType>`; changed Rust struct layouts across addon versions where a cached JS-side handle from an old build is reused; generic code assuming a single boxed type.

AI-assisted analysis of neon-bindings/neon@38960e4381 (2026-09-13). Data as JSON: /api/errors/cf8fe8902776a0cb. Report an issue: GitHub.

Appendix: source

Thrown at crates/neon/src/types_impl/boxed.rs:216

    unsafe fn from_local(env: Env, local: raw::Local) -> Self {
        let raw_data = unsafe { maybe_external_deref(env, local) }
            .expect("Failed to unwrap napi_external as Box<Any>")
            .downcast_ref()
            .expect("Failed to downcast Any");

        Self(JsBoxInner { local, raw_data })
    }

View on GitHub (pinned to 38960e4381)