Summary
The mixed_2_charon_2_pluto smoke scenario exempts the sched log topic from the Warn Log Rate alert, on the stated grounds that Pluto does not serve /charon/priority/2.0.0. That rationale no longer holds: priority + infosync wiring landed in #574 (3c031a6e, 31 July). The exclusion may now be hiding a real regression, or may simply be dead weight — nobody has re-run the scenario without it.
Evidence
The exclusion and its rationale: smoke_test.go#L239-L244
The same claim is repeated on the knob's doc comment: config.go#L166-L171
Pluto serves the protocol:
prioritiser.rs#L46 — PROTOCOL_ID = "charon/priority/2.0.0", cross-checked against the Charon wire token in interop_protocol_id.rs.
pluto_priority::protocols() is included in the node's advertised protocol set in node/behaviour.rs.
run_node starts the priority component and wire_core_workflow registers the per-epoch infosync trigger as a slot subscriber.
The remaining TODO(#402 part B) in node/mod.rs covers routing the decided priority result into ConsensusController, which is a no-op while QBFTv2 is the only protocol. It does not affect the serving side, so it does not justify suppressing the alert.
Work
Acceptance
- No smoke scenario suppresses a log topic with a rationale that is not true of the current code.
mixed_2_charon_2_pluto passes with whatever alert configuration it ends up with.
Summary
The
mixed_2_charon_2_plutosmoke scenario exempts theschedlog topic from the Warn Log Rate alert, on the stated grounds that Pluto does not serve/charon/priority/2.0.0. That rationale no longer holds: priority + infosync wiring landed in #574 (3c031a6e, 31 July). The exclusion may now be hiding a real regression, or may simply be dead weight — nobody has re-run the scenario without it.Evidence
The exclusion and its rationale:
smoke_test.go#L239-L244The same claim is repeated on the knob's doc comment:
config.go#L166-L171Pluto serves the protocol:
prioritiser.rs#L46—PROTOCOL_ID = "charon/priority/2.0.0", cross-checked against the Charon wire token ininterop_protocol_id.rs.pluto_priority::protocols()is included in the node's advertised protocol set innode/behaviour.rs.run_nodestarts the priority component andwire_core_workflowregisters the per-epoch infosync trigger as a slot subscriber.The remaining
TODO(#402 part B)innode/mod.rscovers routing the decided priority result intoConsensusController, which is a no-op while QBFTv2 is the only protocol. It does not affect the serving side, so it does not justify suppressing the alert.Work
mixed_2_charon_2_plutoscenario withconf.AlertWarnExcludeTopicsunset and inspectapp_log_warn_total{topic="sched"}on the Charon nodes.AlertWarnExcludeTopicsdoc comment inconfig.go— its worked example is this scenario.mixed_2_charon_2_plutois its only user; if the exclusion is dropped, the knob has none.TestWriteAlertRulescovers the mechanism, so removing it means removing that case too.Acceptance
mixed_2_charon_2_plutopasses with whatever alert configuration it ends up with.