Skip to content

[alerts] add explicit versions to alert payloads#10555

Open
hawkw wants to merge 3 commits into
mainfrom
eliza/alert-versions
Open

[alerts] add explicit versions to alert payloads#10555
hawkw wants to merge 3 commits into
mainfrom
eliza/alert-versions

Conversation

@hawkw

@hawkw hawkw commented Jun 5, 2026

Copy link
Copy Markdown
Member

This branch adds an explicit notion of version numbers for alert payloads. This is implemented by changing the entry points for publishing alerts (either via Nexus::alert_publish or SitrepBuilder::request_alert for FM) to take a new AlertPayload trait implemented by types which describe alert payloads. These must provide an alert class and version constant, in addition to implementing serde::Serialize and JsonSchema. Eventually we will also use these to generate the schemas for each version of the alert so that they can be communicated to potential consumers. For now, though, we are at least enforcing that a given schema always provides the same alert class and version number (rather than being able to pass in any arbitrary class).

Now, when an alert is created, the schema version is recorded in the alert record. We backfill any existing alert records as being version 0. This doesn't actually matter because, you know, there aren't any, but we may as well do the right thing there. When an alert is delivered to a webhook receiver, the version number is included in a JSON field and a new x-oxide-alert-version header.

This branch adds an explicit notion of version numbers for alert
payloads. This is implemented by changing the entry points for
publishing alerts (either via `Nexus::alert_publish` or
`SitrepBuilder::request_alert` for FM) to take a new `AlertPayload`
trait implemented by types which describe alert payloads. These must
provide an alert class and version constant, in addition to implementing
`serde::Serialize` and `JsonSchema`. Eventually we will also use these
to generate the schemas for each version of the alert so that they can
be communicated to potential consumers. For now, though, we are at least
enforcing that a given schema always provides the same alert class and
version number (rather than being able to pass in any arbitrary class).

Now, when an alert is created, the schema version is recorded in the
alert record. We backfill any existing alert records as being version 0.
This doesn't actually matter because, you know, there aren't any, but we
may as well do the right thing there. When an alert is delivered to a
webhook receiver, the version number is included in a JSON field and a
new `x-oxide-alert-version` header.
@hawkw hawkw added this to the 21 milestone Jun 5, 2026
@hawkw hawkw requested review from mergeconflict and smklein June 5, 2026 21:16
@hawkw hawkw added nexus Related to nexus fault-management Everything related to the fault-management initiative (RFD480 and others) labels Jun 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

fault-management Everything related to the fault-management initiative (RFD480 and others) nexus Related to nexus

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant