feat(CCHAIN-908)!: Add ReceivedProposal host message for proposal-only mode#1110
feat(CCHAIN-908)!: Add ReceivedProposal host message for proposal-only mode#1110
ReceivedProposal host message for proposal-only mode#1110Conversation
Codecov ReportAttention: Patch coverage is
✅ All tests successful. No failed tests found. Additional details and impacted files@@ Coverage Diff @@
## main #1110 +/- ##
==========================================
+ Coverage 76.49% 76.84% +0.35%
==========================================
Files 164 164
Lines 17705 17730 +25
Branches 17705 17730 +25
==========================================
+ Hits 13542 13623 +81
+ Misses 3284 3215 -69
- Partials 879 892 +13
Flags with carried forward coverage won't be shown. Click here to find out more.
|
romac
force-pushed
the
romac/recv-proposal-msg
branch
from
f0ce450 to
be33136
Compare
romac
force-pushed
the
romac/recv-proposal-msg
branch
2 times, most recently
from
a524ab2 to
bb869a1
Compare
romac
changed the title
ReceivedProposal host message for proposal-only modeReceivedProposal host message for proposal-only mode
cason
left a comment
cason
left a comment
There was a problem hiding this comment.
Thanks for this, sounds good.
I don't know exactly how to test this.
If we are running in ProposalAndParts mode, the application is receiving the AppMsg::ReceivedProposal message. What is the real point of this? Do you want to enable the flow: receive Proposal, know what to get from the network, receive parts, reassemble parts, validate parts against Proposal, reply to consensus?
romac
force-pushed
the
romac/recv-proposal-msg
branch
from
2991b6e to
378a73a
Compare
cason
left a comment
cason
left a comment
There was a problem hiding this comment.
I think that following ADR 003, we should not send this event to the application in the ProposalAndParts mode.
Also, we should empathise (more) that the reply to this message is the same value included in the Proposal plus, the most important, the its validity.
| ); | ||
| } | ||
|
|
||
| if state.params.value_payload.proposal_only() { |
| reply_to.send(rx.await?)?; | ||
| } | ||
|
|
||
| // Received a Proposal message in proposal-and-parts mode |
There was a problem hiding this comment.
If we want to follow the ADR, we should not sent anything to the application in this case.
Note that in that case we should not receive a Proposal message ever
In ProposalAndParts mode, the host is merely notified of received proposals and does not need to reply. Using call_and_forward created an RPC reply port that would never receive a response, causing it to leak. Use cast (fire-and-forget) instead. Extract the proposal forwarding logic into a dedicated forward_proposal_to_host helper method on the Consensus actor. Also update BREAKING_CHANGES.md and ADR-003 to reflect that ProposalOnly mode is now fully supported. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
romac
force-pushed
the
romac/recv-proposal-msg
branch
from
5a83f38 to
7e74560
Compare
|
|
Development of this PR has moved to a different repository. |
3 participants
Extracted from #1066
TODO
PR author checklist
For all contributors
RELEASE_NOTES.mdif the change warrants itBREAKING_CHANGES.mdif the change warrants itFor external contributors