Skip to content

fix: remove unsafe code in resolve_error - #7447

Open
brice-stacks wants to merge 2 commits into
stacks-network:feat/clarity-wasm-developfrom
brice-stacks:fix/remove-unsafe
Open

fix: remove unsafe code in resolve_error#7447
brice-stacks wants to merge 2 commits into
stacks-network:feat/clarity-wasm-developfrom
brice-stacks:fix/remove-unsafe

Conversation

@brice-stacks

Copy link
Copy Markdown
Contributor

No description provided.

Comment on lines +10151 to +10155
// `wasmtime::Error` is `anyhow::Error`, so `downcast` peels off any
// context layers and returns the original error by value. Since
// `VmExecutionError` reports no `source()`, a successful
// `root_cause()` match implies it is the payload, so `downcast`
// finds it too.

@Acaccia-stacks Acaccia-stacks Jul 29, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not convinced here. We are using an assumption that wasmtime::Error implementation will not change. We have no guarantee it's the case.
The unsafe code is tried and true and will remain correct if Wasmtime changes its error implementation.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the unsafe version also relies on that assumption. We'd really prefer not to use unsafe unless it is necessary, like in loading the wasm module. At least an issue with this version would cause a compile-time error, not strange runtime behavior.

@Acaccia-stacks Acaccia-stacks Jul 30, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There wouldn't be more of a compile-time error actually, both root_cause and downcast are part of anyhow, so both would have a compilation error in this case. My bad, I thought downcast was part of std::error.

@Acaccia-stacks Acaccia-stacks Jul 30, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

However, with the new code, if the error becomes something like
anyhow::Error::new(UnknowNewErr) where UnknownNewErr::source() is &VmExecutionError,
downcast won't be able to find the VmExecutionError, while root_cause.downcast_ref would.

However, it seems that root_cause.downcast_ref would fail if one day, VmExecutionError's source isn't a None anymore... :D

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about we add this after the downcast check?

        debug_assert!(
            !e.root_cause().is::<VmExecutionError>(),
            "VmExecutionError reachable via root_cause() but not downcast(): {e:?}"
        );

@Acaccia-stacks Acaccia-stacks Jul 31, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup, sounds great!
Why not just assert! though? I don't like debug_assert! because it creates different execution paths between debug and release...

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I used the debug_assert! to avoid any overhead in release builds, since this is not something that we need to check every time, it should either fail in tests, or never fail at all.

The goal here would be to catch this case early and clearly in tests.
@Acaccia-stacks

Copy link
Copy Markdown

@brice-stacks , a little follow-up on our discussion yesterday, where I said we could avoid the unsafe code if we could make VmExecutionError implement Clone.
It doesn't seem obvious to me how we could do it easily, since some WasmError wrap the wasmtime errors, which are acutally anyhow errors, which cannot be cloned...

@brice-stacks

Copy link
Copy Markdown
Contributor Author

@brice-stacks , a little follow-up on our discussion yesterday, where I said we could avoid the unsafe code if we could make VmExecutionError implement Clone. It doesn't seem obvious to me how we could do it easily, since some WasmError wrap the wasmtime errors, which are acutally anyhow errors, which cannot be cloned...

Bummer. Ok, I'll come back to this and investigate a bit more.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants