ref(aci): decouple detector from workflowfirehistory in API #102918
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
github-actions
bot
added
the
Scope: Backend
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
| detector_subquery = DetectorGroup.objects.filter( | ||
| group=OuterRef("group"), | ||
| detector_id__in=DetectorWorkflow.objects.filter(workflow=workflow).values("detector_id"), | ||
| ).values("detector_id")[:1] |
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
src/sentry/workflow_engine/endpoints/serializers/workflow_group_history_serializer.py
Outdated
Show resolved
Hide resolved
![semgrep-code-getsentry[bot]](https://avatars.githubusercontent.com/in/1153895?s=60&v=4){kind=small}
src/sentry/workflow_engine/endpoints/serializers/workflow_group_history_serializer.py
Outdated
Show resolved
Hide resolved
src/sentry/workflow_engine/endpoints/serializers/workflow_group_history_serializer.py
Outdated
Show resolved
Hide resolved
Member
Author
|
Having second thoughts on whether we should do this because the detector in the notification is so tightly coupled with the metric detector code (charts, open periods, etc) |
Member
Author
|
OK we back. We will decouple detector from action.trigger here #103000 |
Comment on lines
131
to
136
| group=OuterRef("group"), | ||
| detector_id__in=DetectorWorkflow.objects.filter(workflow=workflow).values("detector_id"), | ||
| ).values("detector_id")[:1] | ||
|
|
||
| qs = ( | ||
| filtered_history.select_related("group", "detector") | ||
| filtered_history.select_related("group") | ||
| .values("group") | ||
| .annotate(count=Count("group")) | ||
| .annotate(event_id=Subquery(group_max_dates.values("event_id"))) | ||
| .annotate(last_triggered=Max("date_added")) | ||
| .annotate(detector_id=Subquery(group_max_dates.values("detector_id"))) | ||
| .annotate(detector_id=Subquery(detector_subquery)) |
There was a problem hiding this comment.
Bug: The DetectorGroup subquery fails for old groups lacking DetectorGroup entries, causing incorrect detector_id reporting.
Severity: CRITICAL | Confidence: 0.98
🔍 Detailed Analysis
The detector_subquery in workflow_group_history_serializer.py assumes that a DetectorGroup entry exists for every WorkflowFireHistory record with a detector_id. This assumption is false for groups created before the introduction of DetectorGroup entries. When a workflow fires for such an 'old' group, a WorkflowFireHistory record is created with a detector_id, but no corresponding DetectorGroup entry exists. Consequently, the subquery returns None, leading the API to incorrectly report detector=None for these groups, despite a detector having fired the workflow.
💡 Suggested Fix
Modify the detector_subquery in workflow_group_history_serializer.py to correctly retrieve the detector_id for groups that lack a DetectorGroup entry, potentially by falling back to WorkflowFireHistory.detector_id or ensuring DetectorGroup entries are backfilled.
🤖 Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.
Location:
src/sentry/workflow_engine/endpoints/serializers/workflow_group_history_serializer.py#L130-L141
Potential issue: The `detector_subquery` in `workflow_group_history_serializer.py`
assumes that a `DetectorGroup` entry exists for every `WorkflowFireHistory` record with
a `detector_id`. This assumption is false for groups created before the introduction of
`DetectorGroup` entries. When a workflow fires for such an 'old' group, a
`WorkflowFireHistory` record is created with a `detector_id`, but no corresponding
`DetectorGroup` entry exists. Consequently, the subquery returns `None`, leading the API
to incorrectly report `detector=None` for these groups, despite a detector having fired
the workflow.
Did we get this right? 👍 / 👎 to inform future reviews.
Member
Author
There was a problem hiding this comment.
We expect groups that don't have DetectorGroup entries to be attributed to the issue stream detector. You also can't click into the issue stream detector in the UI
cathteng
commented
Nov 10, 2025
src/sentry/workflow_engine/endpoints/serializers/workflow_group_history_serializer.py
Outdated
Show resolved
Hide resolved
This was referenced Nov 10, 2025
cathteng
force-pushed
the
cathy/aci/decouple-detector-workflowfirehistory
branch
from
2ad1498 to
de1b9cc
Compare
Comment on lines
+125
to
+128
| detector_subquery = DetectorGroup.objects.filter( | ||
| group=OuterRef("group"), | ||
| ).values( | ||
| "detector_id" | ||
| )[:1] |
There was a problem hiding this comment.
High severity vulnerability may affect your project—review required:
Line 125 lists a dependency (django) with a known High severity vulnerability.
ℹ️ Why this matters
Affected versions of Django are vulnerable to Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection'). SQL injection in Django's ORM column aliases: when using QuerySet.annotate(), QuerySet.alias(), QuerySet.aggregate(), or QuerySet.extra() with dictionary expansion (**kwargs), the dictionary keys are used unescaped as SQL column aliases. On MySQL and MariaDB backends, an attacker who can influence those keys (for example, by passing a crafted dict of annotations) can inject arbitrary SQL into the generated query.
To resolve this comment:
Check if you are using Django with MySQL or MariaDB.
- If you're affected, upgrade this dependency to at least version 5.2.7 at uv.lock.
- If you're not affected, comment
/fp we don't use this [condition]
💬 Ignore this finding
To ignore this, reply with:
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
You can view more details on this finding in the Semgrep AppSec Platform here.
cathteng
force-pushed
the
cathy/aci/decouple-detector-workflowfirehistory
branch
from
de1b9cc to
73205e2
Compare
❌ 3 Tests Failed:
View the top 3 failed test(s) by shortest run time
To view more test analytics, go to the Test Analytics Dashboard |
kcons
reviewed
Nov 21, 2025
| group=OuterRef("group"), | ||
| ).values( | ||
| "detector_id" | ||
| )[:1] |
Member
There was a problem hiding this comment.
What happens with this subquery when there isn't a DetectorGroup? Groups do exist visibly before DetectorGroup for a short period, but also our backfill isn't quite finished.
This is my only concern at this point.
Member
Author
There was a problem hiding this comment.
It will return None and the frontend will assume it's associated with the issue stream detector (maybe not implemented yet but it will)
kcons
approved these changes
Nov 21, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Since we now have
DetectorGrouprows being written, we could refactor theWorkflowGroupHistoryAPI to useDetectorGroup, rather than use a column onWorkflowFireHistory(which shouldn't need to know which detector triggered the workflow to be fired).Don't use
DetectorWorkflowto check for active detector - workflow connections because a detector might have been disconnected from the workflow since the workflow was triggered for that issue.