Skip to content

ref(seer): Compose automations from a trigger and an action - #130846

Open
trevor-e wants to merge 9 commits into
masterfrom
telkins/seer-workflow-trigger-action
Open

trevor-e wants to merge 9 commits into
masterfrom
telkins/seer-workflow-trigger-action

Conversation

@trevor-e

@trevor-e trevor-e commented Nov 11, 2026 •

Copy link
Copy Markdown
Member

Seer automations were built on a SeerWorkflow base class with one subclass per kind. Each subclass mixed how runs start, which projects they cover and what Seer does, and each carried its own copy of run admission; the two copies had drifted and both locked the config row twice.

This replaces the subclasses with composition. A WorkflowDefinition pairs a trigger with an action, and a config's strategy picks the pairing in workflows/definitions.py: MetricAlertTrigger with InvestigateBreachedMetricAction, and ScheduleTrigger with PromptedInvestigationAction (dispatch still unimplemented, as before). Triggers declare the inputs they produce and actions the inputs they accept, so a mismatched pairing is a mypy error. Admission lives once on the definition and locks the config once. Start with workflows/base.py for the interfaces, then breached_metrics.py, which now also holds the alert handler from action.py.

Behavior changes to review:

  • A metric automation always gets its backing alert workflow at creation, including with no monitors. Previously one created without monitors had none until a monitor selection was first saved.
  • Scheduled runs record their admission decision on the run, as breach runs already did.
  • The seer.workflow.created log no longer carries project or monitor fields; monitor changes at creation log as seer.workflow.monitors_updated.
  • Triggers and actions declare settings (cron, prompt) that are validated on create and update. They are stored in the config's extras and not exposed through the API yet.

Seer automations were built on a SeerWorkflow base class with a subclass per kind. Each subclass mixed how runs start, which projects they cover and what Seer does, and each had its own copy of run admission, with its own config locking.

Replace the subclasses with composition. A WorkflowDefinition pairs a trigger with an action, and a config's strategy picks the pairing. Admission (dedupe, quota, run creation) lives once on the definition and takes the config lock once. Each trigger's code, including the entry point that receives its firings, is in one module: metric_alert.py and schedule.py.

Triggers and actions declare the settings they take, validated on create and update. Settings are kept in the config's extras for now. Runs are created through SeerWorkflowRunLifecycle.

Remove the monitor cleanup test automation, its trigger endpoint, and the older run helpers that only it used.
@github-actions github-actions Bot added the Scope: Backend Automatically applied to PRs that change backend components label Nov 11, 2026
@sentry

sentry Bot commented Nov 11, 2026 •

Copy link
Copy Markdown
Contributor

Sentry Snapshot Testing

Name Added Removed Changed Renamed Unchanged Skipped Status
sentry-frontend
sentry-frontend
0 0 0 0 812 0 ✅ Unchanged

⚙️ sentry-frontend Snapshot Settings

_create_config was shared by two creation paths. With a single create it only added indirection.
Restore the monitor cleanup automation and the run helpers it uses so their removal can be reviewed as its own change.
A metric automation created with no monitors had no backing alert workflow until a monitor selection was first saved. Create it with the automation so every metric automation has one.
Leave the cadence task and its tests in their existing files so the refactor does not also move them.
…ow-trigger-action

# Conflicts:
#	tests/sentry/seer/workflows/test_scheduled.py
Leave the metric alert trigger in breached_metrics.py so the refactor shows as edits to the existing file.
Overload create per strategy so a project selection on a metric automation, or a monitor selection on a scheduled one, is a type error. The configs endpoint branches on the strategy it was sent so each call matches an overload.
@trevor-e
trevor-e marked this pull request as ready for review November 12, 2026 00:56
@trevor-e
trevor-e requested review from a team as code owners November 12, 2026 00:56

This branch was successfully deployed

1 active (outdated) deployment
Preview — edd77898 Deployed Nov 11, 2026 by vercel[bot]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Scope: Backend Automatically applied to PRs that change backend components

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant