these are invalid fields for a first seen event condition, idk why this test was using them so I just changed it to a different condition

This is mainly unsupported conditions

This is sort of hacky but outside of changing the value type of one of these it's the only way for the tests to pass and the serializers to be in sync.

I use the dual written workflow rather than the single written workflow so that it's set up exactly the same as the rule for comparison purposes when editing. I could have created the single written workflow to be the same but this was already here so it was slightly easier to use.

Tests compare wrong workflow missing coverage for specific rules

Medium Severity

In test_remove_conditions and test_reenable_disabled_rule, new rules are created and modified, but the workflow comparison uses self.fake_dual_written_workflow_id, which is tied to the original self.rule, not the newly created rules. This means test_remove_conditions doesn't actually test removing conditions from the correct workflow, and test_reenable_disabled_rule doesn't test re-enabling a disabled workflow (since the dual-written workflow was never disabled). Both tests pass coincidentally because the same payload is applied to both objects, hiding potential real bugs.

 

PUT response serializer missing project_slug parameter

Medium Severity

The WorkflowEngineRuleSerializer() in the PUT response is instantiated without project_slug or prepare_component_fields, unlike the GET handler which passes project_slug=project.slug and prepare_component_fields=True. This means the PUT response may serialize the workflow with missing or incorrect project information and unprepared SentryApp component fields, producing an inconsistent response compared to what GET returns for the same workflow.

 

That's consistent with the RuleSerializer usage

Falsy frequency check silently ignores invalid values

Low Severity

The check if not request_data.get("config", {}).get("frequency") uses a falsy test, so a frequency of 0 (or any other falsy value) silently falls back to workflow.config instead of being passed to the WorkflowValidator for proper rejection. This means an explicitly invalid frequency input gets silently replaced with the saved value rather than producing a validation error.

 

Bug: Updating a workflow rule with an empty action_filters list deletes all filters, causing an IndexError in the serializer which assumes at least one filter exists.
_{Severity: HIGH}

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/api/endpoints/project_rule_details.py#L241-L244

Potential issue: When a workflow rule is updated via a PUT request and the
`action_filters` payload is empty, the `remove_items_by_api_input` function deletes all
associated `WorkflowDataConditionGroup` entries. Subsequently, when the updated rule is
serialized, the `WorkflowEngineRuleSerializer` attempts to access
`workflow.prefetched_wdcgs[0]`. Because all filters were removed, `prefetched_wdcgs` is
an empty list, leading to an `IndexError: list index out of range` and a 500 Internal
Server Error response to the user. The serializer incorrectly assumes at least one
action filter will always be present.

noted

PUT response serializer missing project_slug parameter

Medium Severity

The PUT handler's response creates WorkflowEngineRuleSerializer() with no arguments, while the GET handler creates it with expand, prepare_component_fields=True, and project_slug=project.slug. This means the PUT response may serialize differently than the GET response for the same workflow — notably missing sentry app component field preparation and the project_slug context.