-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mismatching a contract id to an interface produces less than helpful errors. #1437
Comments
@stellar/contract-committers The error message when a function is called that doesn't exist on the contract could be reworded so it speaks into a larger audiences vocab. Most devs probably won't immediately understand that "WasmVm, MissingValue", or "invoking unknown export", mean they're calling a contract function that doesn't exist. We could replace "invoking unknown export" with "invoking unknown function, the following functions are available: <list of functions>". Maybe we could also replace "MissingValue" with "UnknownFunction", or would that be a protocol change? Wdyt? |
Yeah, this message is technically correct (because it's possible to e.g. export a variable and that check will pass). But for the sake of simplicity, we can just say that an unknown function is being called.
That might be tricky to add. I think just pointing at which function is being called and maybe a contract id (if we have it around) should be good enough most of the time. In general, due to the way metering and logging interact, it's hard to build entirely new objects, especially when they're non-trivial and require additional processing (like export lists).
That's a protocol change as we don't even have UnknownFunction error code. In general, our error space is quite limited (by design) and TBH I don't see much value in it most of the time, besides a few cases where we simply can't attach any message to the error. Maybe we should consider changing the rendering of diagnostic events to highlight the message and its arguments (when present), then either omit the error codes completely (given that message is present), or at least render them as the last and the least important piece of information. |
👍🏻 Finding a balance and improving what we can while limiting the cost of doing so and without making a protocol change sounds good to me. If that means updating the message to "invoking unknown function" and including the contract id and the attempted function name, that sounds great 👏🏻. |
Actually the necessary pieces are already there (both contract address and the function name), so technically we need to only change the message. But I think this highlights the issue of the diagnostic event rendering; it's not too hard for us to add placeholders to the event message, and then we could render this as something like the following: "Encountered error in contract Of course that doesn't concern this particular message, I just think we can do better on error presentation in general. |
What version are you using?
soroban-sdk = "21.3.0"
And specifically using an
Env
build from asnapshot.json
let env = Env::from_ledger_snapshot_file("snapshot.json");
What did you do?
I loaded in a SAC contract from an
Address
that wasn't a SAC. (My bad I know, but an innocent mistake)I got an error I wasn't sure how to grok
What did you expect to see?
A more helpful error. Maybe using words like functions or bad/unknown interface. I didn't understand the
"invoking unknown export"
. What export?What did you see instead?
Error logs that didn't help much in clueing me into having the wrong interface for the SAC.
The text was updated successfully, but these errors were encountered: