Repository navigation
[Protocol Versioning] Rules when to Accept or Reject an update Service Event #7143
Description
Overarching Product Goal
This issue is part of Epic #6999. The overall goal is to evolve Versioning of Execution Stack to use the Dynamic Protocol State, and subsequently employ this versioning information for
- coordinating EN HCUs (see Flip 298 for more context on product relevance and impact)
- the ANs to supports script execution across breaking HCU version boundaries (see OKR description for more context on product relevance and impact)
This issue is part of 1.
Detailed Task Description
The following is a list of areas that we identified as needing precise specifications. However, this list is likely not complete:
- Define criteria for rejecting service events
- e.g. rejecting version downgrades unless explicitly forced via dedicated flag. - Specify upper and lower bounds for execution weights and memory limits.
- Additional criteria (?)
Further Reading:
Activity
[-]rules for deciding when to accepted or rejected an update should be[/-][+][Protocol Versioning] Rules ehen to Accept or Reject an update Service Event[/+][-][Protocol Versioning] Rules ehen to Accept or Reject an update Service Event[/-][+][Protocol Versioning] Rules when to Accept or Reject an update Service Event[/+]github-actions commentedon Jun 9, 2025
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
fxamacker commentedon Nov 22, 2025
I created a notion doc "New Service Events to Upgrade Execution Stack".
It proposes new services events for upgrading components and execution parameters. It also outlines validation rules and examples for the specified service vents.
Next step is for cadence, execution, and protocol teams to align on the document.
In the meantime, I am onboarding for issue #7135, etc. and working on a POC to replace the existing Stop Control component.
fxamacker commentedon Dec 17, 2025
After async discussions with Alex about handling unknown components, I proposed a newer approach that would avoid the need to modify the protocol state model for some use cases, and added it to the existing informal design/brainstorming notion doc.
After gathering more feedback, Alex and I had a meeting on Dec. 11, 2025 to go over the pros and cons of each approach described as well as my replies to the feedback/questions.
Our meeting went very well and we are on the same page. We covered every item and the pros/cons listed in the items to discuss notion.
So far, we think it would be worthwhile to use the proposed new
UpgradeabilityComponentto manage component set and reject unknown components. It can help us address our mutual concerns about error handling, reducing human errors, and avoiding catastrophic network failure.Currently, I'm creating a new doc that provides more detail and it is more focused on the proposed new approach (it will be easier to review than adding more details to the old doc).
Next, we'll meet with others from the protocol and execution teams to get their reviews/feedback.
Caveat
One caveat is that some of the work already completed in the protocol state model will need to be modified if we move forward with the new design (assuming everyone is OK with new the design and we proceed with it).