search

AztecProtocol / aztec-packages

Apache License 2.0
172 stars 178 forks source link

error not propagating on oracle failure: #3177

Open Maddiaa0 opened 10 months ago

Maddiaa0 commented 10 months ago

this issue is linked to https://github.com/AztecProtocol/aztec-packages/issues/2946, making it hard to debug what the true issue was under the hood.

When attempting to access the note shown here, https://github.com/Philogy/noirder-book/blob/d3ea292fb2fe72858399a621d1ba2078d7610cb9/contracts/trader/src/main.nr#L53

Which is declared as an immutable note here: https://github.com/Philogy/noirder-book/blob/d3ea292fb2fe72858399a621d1ba2078d7610cb9/contracts/trader/src/main.nr#L29

IFF the user has NOT added the node to their pxe ( which is why the above issue is linked ), then they receive the following error in the cli: image

Upon increasing the debug level of the sandbox itself, it is revealed that the call crashes due to this error: image

The issue fails in an oracle call, yet the "failed to solve brillig function" error message gives no clue to where and when in the code the issue occured.

( I am not too familiar with the brilig sim, but assume this trap is in brillig itself rather than an acvm panic )

What should the solution look like

A more descriptive message about what error has been encountered, and where it has occured

sirasistant commented 10 months ago

Hmmm I'm thinking that maybe the JSON RPC layer is not propagating the call stack? the message makes sense (the function failed at an assertion that says self.is_some) but the callstack should show the noir call stack. Maybe the passing of the error through JSON rpc is deleting the callstack while keeping the message

sirasistant commented 10 months ago

I think that the issue is: Client asks to send through JSON RPC to the PXE The PXE simulates the account contract, who uses an oracle call to call the app function The called function fetches a note, has an assert is_some to the note The called function explodes, the error contains that message and the noir call stack The error comes back from the PXE to the client, but deleting the noir call stack The error becomes difficult to debug

sirasistant commented 10 months ago

To confirm, I'd print out the resulting SimulationError at the PXE level before coming back to the client to see if there it still retains the info

PhilWindle commented 8 months ago

@sirasistant @Maddiaa0 Is this still relevant?