[Alerting] Consider consolidating context and state action variables

[ymao1]

The alerting framework allows rule types to specify context variables, which are short-lived and only defined for the lifecycle of the rule execution, and state variables, which persist across multiple rule executions. While this distinction makes sense for rule type producers to be aware of, it is a detail that users don't necessarily need to know about. Currently in the UI, when selecting from the action variable dropdown, context variables have a context. prefix and state variables have a state. prefix. We should consider consolidating them under a single prefix and deprecating the outdated ones. Note that on the server side, we will still need to support context. and state. prefixes for older actions because migrating action variables is too brittle.

We could consider using a different prefix altogether like message.* or moving all state variables under the context.* prefix (which would involve fewer deprecations). We should also consider the likeliehood of field clashes if a rule type defines a state and context variable with the same field name (I don't believe this is currently happening).

[elasticmachine]

Pinging @elastic/kibana-alerting-services (Team:Alerting Services)

[pmuellr]

context is only used as a way for a rule to provide variables for use in action parameter mustache templates.

state was designed as a way for a rule to persist data used by the rule executor across executions. And there are two kinds - a state object associated with the rule, and a state object associated with each alert (instance). I believe the state we expose via mustache is the alert state and not the rule state. And I believe Ying did some research and found that only the uptime rule was using alert state.

I think conflating these two is not great, but I can definitely see why it can be confusing to users. We don't want rule providers shaping their state just so it can be more easily accessed as mustache variables, for instance. I don't think we initially envisioned even making the state available as mustache variables - guessing we might have said, way back when "oh, we can add this to the context!" (it was probably me!).

I'd prefer we just remove the state action variable entirely. If a rule has something in state that should be available via mustache variables, they can just make it available via context instead of state. The problem is ... how do we deprecate this, if customers are making use of it today?

[elasticmachine]

Pinging @elastic/response-ops (Team:ResponseOps)

[mikecote]

@cnasikas was this added to the team board to re-triage?

[cnasikas]

Hey @mikecote! I got pinged because of the Team:ResponseOps label and noticed it was on the old board but not the new one. This is why I added it again. Sorry if it was a mistake on my part.

[mikecote]

@cnasikas Gotcha, I see you added response-ops-mx-backlog which is the label we used on issues that are temporarily removed from the board. Perhaps we remove it again but keep the team label?

[cnasikas]

Oh, you are right! I forgot about it 😊. I removed it again.