Skip to content
This repository has been archived by the owner on Jul 22, 2024. It is now read-only.

Improve the error handling in the implementation of the storage_read callback of the NativeSyscallHandler #1064

Open
igaray opened this issue Oct 5, 2023 · 3 comments
Labels

Comments

@igaray
Copy link
Collaborator

igaray commented Oct 5, 2023

The storage_read callback works but it's error handling has an unhandled case and includes dbg! macros which should at most log the error.

https://github.com/lambdaclass/starknet_in_rust/pull/943/files#diff-050b376c364b46aa56077588d77a5939973603c9caf47e452bc0895b5b6cd161R155

@igaray igaray added the native label Oct 5, 2023
@igaray igaray added this to Starknet Oct 5, 2023
@Subbitoooo

This comment was marked as abuse.

@igaray igaray moved this to Todo in Starknet Jan 15, 2024
@fmoletta
Copy link
Contributor

fmoletta commented Feb 2, 2024

The unhandled case represents the case in which a storage read fails because of an external reason (such as failure to read from a database).
In this case returning an error is not the correct behaviour, as this will only propagate the error to the cairo program, making it seem like the error was due to the contract's logic rather than an external failure. As we are adding sandboxing for cairo-native execution.
Would it make sense to let it panick in this case? And let the sandbox handle it/fallback to cairo-vm. Otherwise this would require refactoring the trait itself to be able to "tell" the native context that the execution has failed due to an external failure.
What do you think about this @juanbono?

@juanbono
Copy link
Collaborator

juanbono commented Feb 8, 2024

I'm more in favour of returning a rust Error that can be handled as usual. Because panicking kinds of leak the information that Cairo Native can be run in a sandbox process (and this is not always the case).

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
Status: Todo
Development

No branches or pull requests

4 participants