Include function parameters in error messages #18
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
bisgardo
force-pushed
the
derivative
branch
2 times, most recently
from
ad57eb3 to
7c01f98
Compare
bisgardo
changed the title
For debugging purposes, it's important that error messages include as much relevant information as possible. It's much easier to help a user if they can pass on an accurate error message that they received. But precisely because the messages should be in a form where the user can share it without worrying about leaking secrets (and because such errors may end up in logs that could leak), the messages must not include any confidential data. They should also not be unnecessarily verbose. To implement this, we add the "debug" serialization of the functions' input values to the error message that's returned if the call fails. We use the 'derivative' crate to "redact" fields containing secret or verbose data (i.e. they render as "...").
soerenbf
approved these changes
Apr 29, 2024
|
|
||
| #[test] | ||
| fn identity_issuance_request_parameters_debug() { | ||
| assert_eq!( |
There was a problem hiding this comment.
It gets very hard (for me at least) to read these very long inline equality checks. Would be nice if we could do something like
let actual = ...;
let expected = ...;
assert_eq(actual, expected); // or assert_eq(format("{:?}", actual), expected);
| pub struct GlobalContext { | ||
| #[serde(rename = "onChainCommitmentKey")] | ||
| pub on_chain_commitment_key_hex: String, | ||
| #[derivative(Debug(format_with = "redacted_format"))] |
There was a problem hiding this comment.
Are these meant to only mark things that are secret? Or it here because there are a lot of generators?
There was a problem hiding this comment.
I suppose since it is verbose (you mention secret or verbose in the description).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
For debugging purposes, it's important that error messages include as much relevant information as possible. It's much easier to help a user if they can pass on an accurate error message that they received.
But precisely because the messages should be in a form where the user can share it without worrying about leaking secrets (and because such errors may end up in logs that could leak), the messages must not include any confidential data.
They should also not be unnecessarily verbose.
To implement this, we add the "debug" serialization of the functions' input values to the error message that's returned if the call fails. We use the 'derivative' crate to "redact" fields containing secret or verbose data (i.e. they render as "...").