-
Notifications
You must be signed in to change notification settings - Fork 715
feat: use clarity-serialization in clarity
#6310
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
feat: use clarity-serialization in clarity
#6310
Conversation
…end-on-clarity-serialization
…end-on-clarity-serialization
…end-on-clarity-serialization
…end-on-clarity-serialization
…end-on-clarity-serialization
…ity-depend-on-clarity-serialization
…ity-depend-on-clarity-serialization
Any feedback/thoughts? |
kantai
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This LGTM, just one comment where there's a line that I think has slightly different semantics.
kantai
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
1393537
Codecov Report❌ Patch coverage is ❌ Your project status has failed because the head coverage (64.86%) is below the target coverage (80.00%). You can increase the head coverage or adjust the target coverage.
Additional details and impacted files@@ Coverage Diff @@
## develop #6310 +/- ##
============================================
- Coverage 75.57% 64.86% -10.71%
============================================
Files 555 555
Lines 344533 341181 -3352
============================================
- Hits 260390 221323 -39067
- Misses 84143 119858 +35715
... and 289 files with indirect coverage changes Continue to review full report in Codecov by Sentry.
🚀 New features to boost your workflow:
|
|
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Description
Points for Discussion from #6297:
clarity-serialization, I consolidated all error types into a single CodecError enum with a 1:1 match with the original errors inclarity. However, when converting back to the older error types usingFrom<CodecError>, some variants don’t have a clear or meaningful equivalent. I’ve routed them through generic catch-all cases. Even if the current code doesn't reach those conversions, I am not happy with this mapping strategy and am open to suggestions!Applicable issues
Additional info (benefits, drawbacks, caveats)
Checklist
docs/rpc/openapi.yamlandrpc-endpoints.mdfor v2 endpoints,event-dispatcher.mdfor new events)clarity-benchmarkingrepobitcoin-tests.yml