[alerts] add explicit versions to alert payloads#10555
Open
hawkw wants to merge 3 commits into
Open
Conversation
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 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
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.
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_publishorSitrepBuilder::request_alertfor FM) to take a newAlertPayloadtrait implemented by types which describe alert payloads. These must provide an alert class and version constant, in addition to implementingserde::SerializeandJsonSchema. 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-versionheader.