-
Notifications
You must be signed in to change notification settings - Fork 2
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
Computing a secret contract at a nonexistent address throws exception in core, but never returns error #10
Comments
Cool Bug! Will fix tomorrow or on sunday. |
The related core issue is scrtlabs/enigma-core#131. I suggest to add a test to the core for this fix (@elichai, @lacabra). |
Ok, I was wrong about the source of the crash. But, I can't seem to be able to recreate the crash. |
@lacabra after debugging this, we noticed that the error was printing the trace as well (which had the panic in it). This happens since the error was a Failure error (an error class we use only in the DB code) and when printing the failure error as debug it adds the trace as opposed to display which print's the error only which is what we are supposed to have there. |
…e error without the backtrace. fixxes scrtlabs/discovery-docker-network#10
@lacabra , I added a fix for this issue, please close this issue, if you see it solves the problem. Great catch! |
While I see some change, this still doesn't fix the error, as
|
@elichai it seems that the logs output this backtrace. is there some way to fix this? |
@lacabra it seems that the output you are getting now is actually as a result of the logger you defined when running the core docker. in |
Thanks @AvishaiW, that’s fine. My problem is that error message you mention does not get processed as a failed computation by p2p, and does not get submitted as a failed computation to the contract, and will remain forever as pending, whereas it has failed. So the user that submitted the task has no way to know that computation has failed. Cc: @lenak25 |
@lacabra |
One note about the backtrack that can seem as a panic. This is a result of the combination of these two:
I think that the right thing to do is when we pass errors through sockets or between services we should use the Display trait to avoid accidentally adding backtrace even if we compile with But I don't think this is a concern on logs and local prints because they aren't sent anywhere. more info can be read here: https://docs.rs/failure/0.1.5/failure/struct.Backtrace.html |
…e error without the backtrace. fixxes scrtlabs/discovery-docker-network#10
Describe the bug
This is a Rainy Day Scenario in that when requesting a secret computation for an address that doesn't exist,
core
throws an exception withErr(DBErr { command: "read", kind: MissingKey }
but never returns an error, so the task remains in a pending state forever.To Reproduce
Steps to reproduce the behavior:
Expected behavior
The request should error out properly, so that the final state of that task is
FAILURE
.Backtrace
The text was updated successfully, but these errors were encountered: