Do we really need to specify V2 here? isn't that an implementation detail?

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?

don't have any suggestions atm, maybe @tinnytintin10 could help

Discussed briefly this one with @tinnytintin10, suggestion is to remove V2 from name, as it also felt a bit as implementation detail. The next step will be for us to offer extra metadata for supporting V1 and V2 if you decide to ship something for alerting V1. Also you can explicitly put in the description that this one is related to V2 if that could help users further, wdyt?

@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.ruleSnoozed
payload might be

{
  "rule.id":  "some-id-for-rule",
  "alerting.version": 2,
  "timestamp": //...
    // ...etc
}

for alerting.alertAssigned and alerting.alertAcknowledged, maybe only v2 alerts have these features, but that's still okay.

Thoughts?

do we actually want event-driven triggers for v1?

maybe we can make a deliberate product choice that event driven triggers are v2-only. v1 users still have the run workflow action, so they can invoke workflows when alerts fire or recover. event-driven triggers would only come with v2, and only show up once v2 features are enabled. If users want event driven triggers, that's a reason to move to v2. i think this would enable us to:

1. sidesteps the whole naming question here. If there's never a v1 trigger to disambiguate from, we don't need the version in the ID and can just call it alerting.episodeAssigned.
2. and on the product side, event-driven automation is exactly the kind of capability that pulls people toward v2, instead of us building it twice for a framework we're winding down.

wdyt @jasonrhodes @tiamliu

My first instinct is to say I think this is a really good idea. We need to support v1 rules and alerts for a long time, likely, as users will want to continue using their existing rules and put off migration as long as possible even if we make it easy, but that doesn't mean we need to give v1 rules every new thing.

If we do get pressure to add these down the road, let's let those events bear the burden of naming with something like alerting.classic.{trigger_name} or alerting.legacy.{trigger_name} depending on how far down the road we are when we decide we want it. I may be missing some context that makes this not work, so I'll check with Tia and others on our side, but on first glance I think this is a nice solution.

This is a good middle ground. We can deliberately choose to support event triggers in alerting v2 only. In alerting v1, workflows can be attached as an action and can already be triggered per execution. If we make this a v2 only thing , it also gives users incentive to migrate. Thanks for all your thorough considerations @cnasikas @jasonrhodes @tinnytintin10

Thank you all! I also agree. I will go with alerting.episodeAssigned then. Thanks!

@yngrdyn @tinnytintin10 I pushed the changes. Could you plz take another look?

You probably need to change this as well