Skip to content

ref(automations): Break circular dependency between dataConditionNodes and action filters - #127491

Merged
ryan953 merged 3 commits into
masterfrom
seer/ref/automations-break-data-condition-nodes-cycle-H9omO9
Oct 15, 2026
Merged

ryan953 merged 3 commits into
masterfrom
seer/ref/automations-break-data-condition-nodes-cycle-H9omO9

Conversation

@sentry

@sentry sentry Bot commented Oct 14, 2026 •

Copy link
Copy Markdown
Contributor

eventFrequency.tsx, eventUniqueUserFrequency.tsx and percentSessions.tsx imported dataConditionNodesMap only to look up the defaultComparison for the type a user picks in the "more than... / relatively higher than..." select. dataConditionNodes.tsx imports those same components to build the map, so each file formed a runtime cycle.

The node components now receive a getDefaultComparison prop. Node in dataConditionNodeList.tsx, which renders every condition and already imports the map, supplies it. dataConditionNodes.tsx keeps declaring the defaults inline, so the map stays the single source of truth, and its dataCondition field is now typed with the new DataConditionNodeComponentProps instead of any.

The obvious alternative, extracting the defaults into a separate module that both sides import (what this PR and the duplicates #127489 / #127490 first did), also breaks the cycle but splits the condition registry across two files. A lookup callback is used rather than passing the two default objects directly because the field needs the defaults for the other condition types (COUNT/PERCENT), not the type currently rendered.

A new test in dataConditionNodeList.spec.tsx covers switching an event frequency condition to "relatively higher than..." and checks the percent defaults are applied; no spec covered that path before.

No feature flags.

Legal Boilerplate

Look, I get it. The entity doing business as "Sentry" was incorporated in the State of Delaware in 2015 as Functional Software, Inc. and is gonna need some rights from me in order to utilize my contributions in this here PR. So here's the deal: I retain all rights, title and interest in and to my contributions, and by keeping this boilerplate intact I confirm that Sentry can use, modify, copy, and redistribute my contributions, under Sentry's choice of terms.

Fixes CODING-CONVENTIONS-99M
Fixes CODING-CONVENTIONS-99P
Fixes CODING-CONVENTIONS-99Q

@sentry <feedback>: Autofix iterates on these changes
@sentry stop iterating: Autofix stops iterating on this run

@sentry
sentry Bot requested a review from a team as a code owner October 14, 2026 22:42
@github-actions github-actions Bot added the Scope: Frontend Automatically applied to PRs that change frontend components label Oct 14, 2026
The frequency filter nodes now receive a getDefaultComparison prop from
the node list renderer instead of importing dataConditionNodesMap. That
breaks the cycle without a second module of default values, so
dataConditionNodesMap stays the only place the defaults are declared.

Fixes CODING-CONVENTIONS-99M
Fixes CODING-CONVENTIONS-99P
Fixes CODING-CONVENTIONS-99Q
@ryan953 ryan953 added the Trigger: getsentry tests Once code is reviewed: apply label to PR to trigger getsentry tests label Oct 15, 2026
@ryan953
ryan953 enabled auto-merge (squash) October 15, 2026 04:31
@ryan953
ryan953 merged commit 063eb74 into master Oct 15, 2026
89 of 90 checks passed
@ryan953
ryan953 deleted the seer/ref/automations-break-data-condition-nodes-cycle-H9omO9 branch October 15, 2026 04:31

This branch was successfully deployed

1 active deployment
Preview — 4e2290d7 Deployed Oct 15, 2026 by vercel[bot]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Scope: Frontend Automatically applied to PRs that change frontend components Trigger: getsentry tests Once code is reviewed: apply label to PR to trigger getsentry tests

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant