-
Notifications
You must be signed in to change notification settings - Fork 8.6k
[Alerting V2] Register "assign episode" workflow trigger #268915
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
c6ff65f
6d07213
4eaaa3c
80ac903
c09ec2d
cd3fefd
e43a1b4
9afde85
28a9188
0f8e5c0
068fedd
2714f6f
0c4978c
1dd5101
94de798
c06e33b
741b21f
e7a671b
fe5bd86
ee0a69f
3aafc90
7a15f24
a6569f5
a45ed7f
0a9a061
19b1d78
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,101 @@ | ||
| /* | ||
| * Copyright Elasticsearch B.V. and/or licensed to Elasticsearch B.V. under one | ||
| * or more contributor license agreements. Licensed under the Elastic License | ||
| * 2.0; you may not use this file except in compliance with the Elastic License | ||
| * 2.0. | ||
| */ | ||
|
|
||
| import { i18n } from '@kbn/i18n'; | ||
| import { z } from '@kbn/zod/v4'; | ||
| import type { CommonTriggerDefinition } from '@kbn/workflows-extensions/common'; | ||
|
|
||
| export const EPISODE_ASSIGNED_TRIGGER_ID = 'alertingV2.episodeAssigned' as const; | ||
|
|
||
| export const episodeAssignedPayloadSchema = z | ||
| .object({ | ||
| occurredAt: z.string().describe( | ||
Check failureCode scanning / CodeQL Unbounded string in schema validation High
This z.string() call does not specify a .max() constraint. Unbounded string input can cause Denial of Service (DoS) vulnerabilities. Consider adding .max(N) to the method chain.
|
||
|
|
||
| i18n.translate('xpack.alertingVTwo.triggers.episodeAssigned.schema.occurredAt', { | ||
| defaultMessage: 'ISO timestamp of when the assignment occurred.', | ||
| }) | ||
| ), | ||
| groupHash: z.string().describe( | ||
Check failureCode scanning / CodeQL Unbounded string in schema validation High
This z.string() call does not specify a .max() constraint. Unbounded string input can cause Denial of Service (DoS) vulnerabilities. Consider adding .max(N) to the method chain.
|
||
|
|
||
| i18n.translate('xpack.alertingVTwo.triggers.episodeAssigned.schema.groupHash', { | ||
| defaultMessage: 'Stable hash of the alert grouping the episode belongs to.', | ||
| }) | ||
| ), | ||
| episodeId: z.string().describe( | ||
Check failureCode scanning / CodeQL Unbounded string in schema validation High
This z.string() call does not specify a .max() constraint. Unbounded string input can cause Denial of Service (DoS) vulnerabilities. Consider adding .max(N) to the method chain.
|
||
|
|
||
| i18n.translate('xpack.alertingVTwo.triggers.episodeAssigned.schema.episodeId', { | ||
| defaultMessage: 'Identifier of the alerting episode whose assignee changed.', | ||
| }) | ||
| ), | ||
| ruleId: z.string().describe( | ||
Check failureCode scanning / CodeQL Unbounded string in schema validation High
This z.string() call does not specify a .max() constraint. Unbounded string input can cause Denial of Service (DoS) vulnerabilities. Consider adding .max(N) to the method chain.
|
||
|
|
||
| i18n.translate('xpack.alertingVTwo.triggers.episodeAssigned.schema.ruleId', { | ||
| defaultMessage: 'Identifier of the alerting rule the episode belongs to.', | ||
| }) | ||
| ), | ||
| spaceId: z.string().describe( | ||
Check failureCode scanning / CodeQL Unbounded string in schema validation High
This z.string() call does not specify a .max() constraint. Unbounded string input can cause Denial of Service (DoS) vulnerabilities. Consider adding .max(N) to the method chain.
|
||
|
|
||
| i18n.translate('xpack.alertingVTwo.triggers.episodeAssigned.schema.spaceId', { | ||
| defaultMessage: 'Kibana space the episode lives in.', | ||
| }) | ||
| ), | ||
| actorUid: z | ||
| .string() | ||
Check failureCode scanning / CodeQL Unbounded string in schema validation High
This z.string() call does not specify a .max() constraint. Unbounded string input can cause Denial of Service (DoS) vulnerabilities. Consider adding .max(N) to the method chain.
|
||
|
Comment on lines
+41
to
+42
|
||
| .nullable() | ||
| .describe( | ||
| i18n.translate('xpack.alertingVTwo.triggers.episodeAssigned.schema.actorUid', { | ||
| defaultMessage: | ||
| 'User-profile uid of the actor who changed the assignee, or null when performed by an internal/system context.', | ||
| }) | ||
| ), | ||
| assigneeUid: z | ||
| .string() | ||
Check failureCode scanning / CodeQL Unbounded string in schema validation High
This z.string() call does not specify a .max() constraint. Unbounded string input can cause Denial of Service (DoS) vulnerabilities. Consider adding .max(N) to the method chain.
|
||
|
Comment on lines
+50
to
+51
|
||
| .nullable() | ||
| .describe( | ||
| i18n.translate('xpack.alertingVTwo.triggers.episodeAssigned.schema.assigneeUid', { | ||
| defaultMessage: | ||
| 'User-profile uid of the new assignee, or null when the episode was unassigned.', | ||
| }) | ||
| ), | ||
| }) | ||
| .strict(); | ||
|
|
||
| export type EpisodeAssignedPayload = z.infer<typeof episodeAssignedPayloadSchema>; | ||
|
|
||
| export const episodeAssignedTriggerCommonDefinition: CommonTriggerDefinition< | ||
| typeof episodeAssignedPayloadSchema | ||
| > = { | ||
| id: EPISODE_ASSIGNED_TRIGGER_ID, | ||
| eventSchema: episodeAssignedPayloadSchema, | ||
| title: i18n.translate('xpack.alertingVTwo.workflowTriggers.episodeAssigned.title', { | ||
| defaultMessage: 'Alerting - Episode assigned', | ||
| }), | ||
| description: i18n.translate('xpack.alertingVTwo.workflowTriggers.episodeAssigned.description', { | ||
| defaultMessage: 'Emitted when an alerting episode is assigned to a user.', | ||
| }), | ||
| documentation: { | ||
| details: i18n.translate( | ||
| 'xpack.alertingVTwo.workflowTriggers.episodeAssigned.documentation.details', | ||
| { | ||
| defaultMessage: | ||
| 'Emitted after an episode assign action is persisted with a non-null assignee. The payload includes event.episodeId, event.ruleId, event.spaceId, and event.assigneeUid for trigger conditions.', | ||
| } | ||
| ), | ||
| examples: [ | ||
| i18n.translate('xpack.alertingVTwo.workflowTriggers.episodeAssigned.documentation.example', { | ||
| defaultMessage: `## Run for a specific rule | ||
| \`\`\`yaml | ||
| triggers: | ||
| - type: {triggerId} | ||
| on: | ||
| condition: 'event.ruleId: "my-rule-id"' | ||
| \`\`\``, | ||
| values: { | ||
| triggerId: EPISODE_ASSIGNED_TRIGGER_ID, | ||
| }, | ||
| }), | ||
| ], | ||
| }, | ||
| snippets: { | ||
| condition: 'event.assigneeUid: "user-profile-uid"', | ||
| }, | ||
| }; | ||
|
cnasikas marked this conversation as resolved.
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,13 @@ | ||
| /* | ||
| * Copyright Elasticsearch B.V. and/or licensed to Elasticsearch B.V. under one | ||
| * or more contributor license agreements. Licensed under the Elastic License | ||
| * 2.0; you may not use this file except in compliance with the Elastic License | ||
| * 2.0. | ||
| */ | ||
|
|
||
| export { | ||
| EPISODE_ASSIGNED_TRIGGER_ID, | ||
| episodeAssignedPayloadSchema, | ||
| episodeAssignedTriggerCommonDefinition, | ||
| } from './episode_assigned'; | ||
| export type { EpisodeAssignedPayload } from './episode_assigned'; |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,24 @@ | ||
| /* | ||
| * Copyright Elasticsearch B.V. and/or licensed to Elasticsearch B.V. under one | ||
| * or more contributor license agreements. Licensed under the Elastic License | ||
| * 2.0; you may not use this file except in compliance with the Elastic License | ||
| * 2.0. | ||
| */ | ||
|
|
||
| import React from 'react'; | ||
| import type { PublicTriggerDefinition } from '@kbn/workflows-extensions/public'; | ||
| import { episodeAssignedTriggerCommonDefinition } from '../../../../common/workflows/triggers'; | ||
|
|
||
| const EpisodeAssignedIcon = React.lazy(() => | ||
| // @ts-expect-error EUI does not ship `.d.ts` files for deep `icon/assets/*` | ||
| // subpaths. Other plugins work around this with an ambient `eui_icons.d.ts` | ||
| // (see e.g. x-pack/platform/plugins/shared/cases/public/workflows/eui_icons.d.ts). | ||
| import('@elastic/eui/es/components/icon/assets/user').then(({ icon }) => ({ | ||
| default: icon, | ||
| })) | ||
| ); | ||
|
|
||
| export const episodeAssignedTriggerPublicDefinition: PublicTriggerDefinition = { | ||
| ...episodeAssignedTriggerCommonDefinition, | ||
| icon: EpisodeAssignedIcon, | ||
| }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we really need to specify
V2here? isn't that an implementation detail?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We want to distinguish between the existing alerting and the new one (v2) in case we want to introduce triggers for the v1 alerting in the future. Any suggestions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
don't have any suggestions atm, maybe @tinnytintin10 could help
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Discussed briefly this one with @tinnytintin10, suggestion is to remove
V2from name, as it also felt a bit as implementation detail. The next step will be for us to offer extra metadata for supportingV1andV2if you decide to ship something for alerting V1. Also you can explicitly put in the description that this one is related toV2if that could help users further, wdyt?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tiamliu based on our recent conversations around how to cater to "mixed experiences" effectively, please check my thinking here?
I think we should call these kinds of events/triggers "alerting.[event_name]" and as much as possible make them version-agnostic. For events that apply to both, we can send them through the same flow, and include "version" as a payload discriminator for people who only want to handle one or the other for some reason (likely suggested by a consultant, support, etc).
Very rough examples:
for
alerting.ruleSnoozedpayload might be
{ "rule.id": "some-id-for-rule", "alerting.version": 2, "timestamp": //... // ...etc }for
alerting.alertAssignedandalerting.alertAcknowledged, maybe only v2 alerts have these features, but that's still okay.Thoughts?
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you both for the suggestions, and really appreciate being thorough here, as the trigger ID is not an internal name, but it is part of the public contract users put in their workflow YAML. For events that genuinely exist in both V1 and V2 with the same schemas, a common payload makes a lot of sense, and it will avoid users from having to configure the same workflow twice, one for V1 and one for V2. Where I would like to push back is that V2 has a totally different philosophy, for example, episodes. V1 has alert instances and recoveries with a different lifecycle, so for a lot of V2 events, there is no conceptually equivalent V1 event to merge with. For these V2 events, the version is always going to be 2, never anything else, and presenting a V2-only trigger as if it were version-agnostic is exactly the confusing mixed experience we're trying to prevent. We move the version from the trigger ID to the payload, which is still user-facing.
Some technical concerns when/if the payload diverges between versions on the same events: When we register a trigger, we need to provide a
zodschema. We need to construct the schema with a discriminated union based onalerting.versionhaving one schema per version. Workflow authors will have to know which fields to use and how to branch between different versions. We would also need to document which field is on which version. Also, if in the future we need to introduce versioning on the schema of the v2 payload (I hope we will never have to do this 🙂 ), we would need to have a second discriminator (alerting.v2.version) for the new schema. Separating the events based on its top level discriminator (the trigger ID) eliminates these issues, especially if each one's schemas want to evolve differently. Lastly, if we namespace on the trigger ID, it will be easier to deprecate v1 triggers in the future while we are deprecating the alerting v1, telemetry, and audit become a bit easier (not scanning the payload to figure out the version), and discoverability in the workflows UI is unambiguous (a user browsing their trigger catalog knows immediately which alerting world it belongs to).On the leaking implementation detail in the trigger ID, I hear the concern, but all of our APIs already have the V2 in their path and are exposed to the users. I would suggest keeping the distinction of v1 and v2 in the trigger ID level (maybe rename it to
alerting.v2.episodeAssignedor something very different) when the events are different, and keep the common event framework agnostic if the events are the same with the same payload.Very happy to be wrong about specific cases, though, and if you got an event in mind where the shared-id pattern works even for V2-only features, I would love to talk it through.