Report proposal errors earlier and more precisely where possible #1441
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1441 +/- ##
==========================================
- Coverage 60.73% 60.67% -0.06%
==========================================
Files 140 140
Lines 16467 16475 +8
==========================================
- Hits 10001 9996 -5
- Misses 6466 6479 +13 ☔ View full report in Codecov by Sentry. |
|
This is now rebased onto main. |
…ases. Signed-off-by: Daira-Emma Hopwood <[email protected]>
daira
changed the title
| /// This is indicative of a programming error; a transaction proposal that presumes | ||
| /// support for the specified pool was decoded or executed using an application that | ||
| /// does not provide such support. | ||
| ProposalNotSupported(ProposalError), |
There was a problem hiding this comment.
I'm not sure that having two different variants that wrap ProposalError is a good idea; it suggests that the entire state space of ProposalError is reachable by multiple paths, but the comment here suggests something different, and that only a subset of ProposalError is reachable via the path that produces ProposalNotSupported.
| ProposalError::SpendsPaymentFromUnsupportedPool(_) | ||
| | ProposalError::PaysUnsupportedPoolRecipient(_) => Error::ProposalNotSupported(e), |
There was a problem hiding this comment.
Should these variants really be a part of ProposalError?
This follow-up to #1257 is not essential, but it improves the error reporting by: