feat(governance): emit distinct supersession event on role re-proposal - #539
Merged
usmanimamu17-create merged 1 commit intoAug 31, 2026
Conversation
propose_admin/propose_operator wrote the pending slot unconditionally, so re-proposing a role silently replaced the pending candidate with no signal in the event stream — an auditor watching adm_prop/op_prop could not distinguish "cancelled then re-proposed" from "silently replaced". Both now emit an additive adm_sup/op_sup event carrying (superseded, replacement) before the new proposal event, so the pending slot's history is fully reconstructable. Registers the two new event names in the event schema and the api_stability guardrail and adds coverage for admin and operator supersession plus the payload shape. Closes ApexChainx#468
|
@beulah7717108-eng Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits. You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀 |
usmanimamu17-create
approved these changes
Aug 31, 2026
usmanimamu17-create
left a comment
usmanimamu17-create
left a comment
Contributor
There was a problem hiding this comment.
Makes sense, approved.
3 tasks
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Summary
propose_admin/propose_operatorwrote the pending slot unconditionally, so re-proposing a role silently replaced the pending candidate with no signal in the event stream. An auditor watchingadm_prop/op_propcould not distinguish "cancelled then re-proposed" from "silently replaced", and the superseded candidate was never told why itsacceptwould now fail.Both now emit an additive
adm_sup/op_supevent carrying(superseded, replacement)before the newadm_prop/op_prop, so the pending slot's history is fully reconstructable.Changes
governance.rs:propose_admin/propose_operatorpublish a supersession event when a proposal is already pending, then publish the new proposal.event_schema.rs/lib.rs: newadm_supandop_supevent constants with payloads documented.api_stability.rs:event_name_symbols()and the guardrail counts updated for the two additive events.tests.rs: coverage for admin and operator supersession, the supersession count across repeated re-proposals, and the payload shape.Tests
api_stability, event_schema, event-ordering and topic-stability suites pass alongside the new supersession tests.
Closes #468