Skip to content

[RnA] Simplify matcher context and Add Rule name to workflow payload#271768

Open
miguelmartin-elastic wants to merge 14 commits into
elastic:mainfrom
miguelmartin-elastic:feat/simplify-matcher-context-517
Open

[RnA] Simplify matcher context and Add Rule name to workflow payload#271768
miguelmartin-elastic wants to merge 14 commits into
elastic:mainfrom
miguelmartin-elastic:feat/simplify-matcher-context-517

Conversation

@miguelmartin-elastic
Copy link
Copy Markdown
Contributor

@miguelmartin-elastic miguelmartin-elastic commented May 28, 2026

Summary

Closes https://github.com/elastic/rna-program/issues/517
Closes https://github.com/elastic/rna-program/issues/499

#517 — Simplify MatcherContext rule fields

Removes description, enabled, createdAt, and updatedAt from MatcherContextRule and MATCHER_CONTEXT_FIELDS. These fields have no use in matcher evaluation logic and add unnecessary noise.

#499 — Add rule metadata to dispatched workflow payload

Adds a rules: Record<ruleId, { name: string }> map to ActionPolicyWorkflowPayload. Workflows can now access rule names via {{ inputs.rules[episode.rule_id].name }} without extra lookups. Data is sourced from the existing state.rules already loaded by FetchRulesStep.

Checklist

@github-actions github-actions Bot added the author:actionable-obs PRs authored by the actionable obs team label May 28, 2026
@miguelmartin-elastic miguelmartin-elastic added backport:skip This PR does not require backporting release_note:skip Skip the PR/issue when compiling release notes labels May 28, 2026
@miguelmartin-elastic miguelmartin-elastic marked this pull request as ready for review May 28, 2026 17:16
@miguelmartin-elastic miguelmartin-elastic requested a review from a team as a code owner May 28, 2026 17:16
Copy link
Copy Markdown
Contributor

@kdelemme kdelemme left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think we can trim the Rule type too, and a few questions on where the rule map should be crafted and stored on? Might be pros/cons in both approach. what do you think?

Comment on lines 54 to 64
export interface Rule {
id: RuleId;
spaceId: string;
kind: 'alert' | 'signal';
name: string;
description: string;
tags: string[];
enabled: boolean;
createdAt: string;
updatedAt: string;
}
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we simplify these as well? We probably don't need most of these fields?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, totally. Done in 45a1572

}

export interface ActionPolicyWorkflowPayloadRule {
name: string;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we add the tags as well?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Happy to add it, but leaning towards YAGNI for now — tags are already available in the matcher context for filtering. Open to adding if you see a concrete use case here 🤔

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tags could be useful for a message but let's wait i agree with you

export interface Rule {
id: RuleId;
spaceId: string;
kind: 'alert' | 'signal';
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we only handle 'alert' kind so might not be useful to keep kind

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in 45a1572 and 8cfa955

policyId: ActionPolicyId;
groupKey: Record<string, unknown>;
episodes: AlertEpisode[];
rules: Record<RuleId, ActionPolicyWorkflowPayloadRule>;
Copy link
Copy Markdown
Contributor

@kdelemme kdelemme May 28, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we trim Rule, can't we use Record<RuleId, Rule> directly?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rule still has some other fields that we don't use in the payload: id, spaceId, tags. What I did instead was to make ActionPolicyWorkflowPayloadRule be a Pick type from Rule in d75f460 Lmkwyt

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good 👍🏻

}

private async dispatchWorkflow(
group: ActionGroup,
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if we make rules (the map one) directly part of the action group?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice. Done in 34426be

Copy link
Copy Markdown
Contributor

@kdelemme kdelemme left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should not rebuild the whole rules map for every episode, build it incrementally

Comment on lines 8 to 12
export interface MatcherContextRule {
id: string;
name: string;
description: string;
tags: string[];
enabled: boolean;
createdAt: string;
updatedAt: string;
}
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Image

Comment on lines +35 to +40
{
path: 'rules',
detail: 'Record<string, { name: string }>',
documentation:
'Rule metadata keyed by rule id. Covers all rules present in `episodes`. Access via `rules[episode.rule_id].name`.',
},
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are going to have some conflict when #271770 land :D

Comment on lines +90 to +92
const group = groupMap.get(actionGroupId)!;
group.episodes.push(episode);
group.rules = buildRulesMap([...new Set(group.episodes.map((e) => e.rule_id))], rules);
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we rebuilding the rules map every time?

I think we can optimize this (you can drop your helper buildRulesMap too)

      const group = groupMap.get(actionGroupId)!;
      group.episodes.push(episode);
      const rule = rules?.get(episode.rule_id);
      if (rule) {
        group.rules[episode.rule_id] = { name: rule.name };
      }

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch wizard 🧙‍♂️ Fixed in 9fcb0eb

@kibanamachine
Copy link
Copy Markdown
Contributor

💚 Build Succeeded

Metrics [docs]

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id before after diff
alertingVTwo 963.2KB 963.2KB +34.0B

History

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

author:actionable-obs PRs authored by the actionable obs team backport:skip This PR does not require backporting release_note:skip Skip the PR/issue when compiling release notes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants