Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion migrations_lockfile.txt
Original file line number Diff line number Diff line change
Expand Up @@ -39,4 +39,4 @@ tempest: 0003_use_encrypted_char_field

uptime: 0049_cleanup_failed_safe_deletes

workflow_engine: 0102_cleanup_failed_safe_deletes
workflow_engine: 0103_action_data_fallthrough_type
Original file line number Diff line number Diff line change
@@ -0,0 +1,47 @@
# Generated by Django 5.2.8 on 2025-11-20 20:02

from django.db import migrations
from django.db.backends.base.schema import BaseDatabaseSchemaEditor
from django.db.migrations.state import StateApps

from sentry.new_migrations.migrations import CheckedMigration
from sentry.utils.query import RangeQuerySetWrapper


def migrate_fallthrough_type(apps: StateApps, schema_editor: BaseDatabaseSchemaEditor) -> None:
Action = apps.get_model("workflow_engine", "Action")
for action in RangeQuerySetWrapper(Action.objects.all()):
if action.data.get("fallthroughType"):
Copy link
Contributor

Choose a reason for hiding this comment

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

Bug: Migration condition skips falsy fallthroughType values

The migration checks if action.data.get("fallthroughType"): which will silently skip any action where fallthroughType exists but is falsy (e.g., None, 0, False, empty string). This could result in data loss. Should use if "fallthroughType" in action.data: to migrate all occurrences of the field regardless of its value.

Fix in Cursor Fix in Web

new_data = action.data.copy()
del new_data["fallthroughType"]
new_data["fallthrough_type"] = action.data["fallthroughType"]
action.data = new_data
action.save()
Comment on lines +11 to +19
Copy link

Choose a reason for hiding this comment

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

Bug: Migration renames fallthroughType to fallthrough_type, but EmailDataBlob expects fallthroughType, causing a TypeError.
Severity: CRITICAL | Confidence: High

🔍 Detailed Analysis

The database migration renames the action.data field fallthroughType to fallthrough_type. However, the EmailDataBlob dataclass, used in EmailIssueAlertHandler.get_additional_fields(), still defines the field as fallthroughType. After the migration, when EmailDataBlob(**action.data) is called, it will receive fallthrough_type as an unexpected keyword argument, leading to a TypeError. This will cause all email-based workflow actions to crash.

💡 Suggested Fix

Update the EmailDataBlob dataclass field from fallthroughType to fallthrough_type to align with the migrated data key.

🤖 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/migrations/0103_action_data_fallthrough_type.py#L11-L19

Potential issue: The database migration renames the `action.data` field
`fallthroughType` to `fallthrough_type`. However, the `EmailDataBlob` dataclass, used in
`EmailIssueAlertHandler.get_additional_fields()`, still defines the field as
`fallthroughType`. After the migration, when `EmailDataBlob(**action.data)` is called,
it will receive `fallthrough_type` as an unexpected keyword argument, leading to a
`TypeError`. This will cause all email-based workflow actions to crash.

Did we get this right? 👍 / 👎 to inform future reviews.
Reference_id: 2862609



class Migration(CheckedMigration):
# This flag is used to mark that a migration shouldn't be automatically run in production.
# This should only be used for operations where it's safe to run the migration after your
# code has deployed. So this should not be used for most operations that alter the schema
# of a table.
# Here are some things that make sense to mark as post deployment:
# - Large data migrations. Typically we want these to be run manually so that they can be
# monitored and not block the deploy for a long period of time while they run.
# - Adding indexes to large tables. Since this can take a long time, we'd generally prefer to
# run this outside deployments so that we don't block them. Note that while adding an index
# is a schema change, it's completely safe to run the operation after the code has deployed.
# Once deployed, run these manually via: https://develop.sentry.dev/database-migrations/#migration-deployment

is_post_deployment = False

dependencies = [
("workflow_engine", "0102_cleanup_failed_safe_deletes"),
]

operations = [
migrations.RunPython(
code=migrate_fallthrough_type,
reverse_code=migrations.RunPython.noop,
hints={"tables": ["workflow_engine_workflowfirehistory"]},
Copy link
Contributor

Choose a reason for hiding this comment

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

Bug: Migration hints specify wrong table name

The migration operates on the Action model but specifies workflow_engine_workflowfirehistory in the hints. This incorrect table name can cause database routing and failover issues in sharded/replicated environments. The hints should specify workflow_engine_action to match the table being modified.

Fix in Cursor Fix in Web

),
]
Original file line number Diff line number Diff line change
@@ -0,0 +1,40 @@
from sentry.notifications.models.notificationaction import ActionTarget
from sentry.notifications.types import FallthroughChoiceType
from sentry.testutils.cases import TestMigrations
from sentry.workflow_engine.models import Action


class TestActionDataFallthroughType(TestMigrations):
migrate_from = "0102_cleanup_failed_safe_deletes"
migrate_to = "0103_action_data_fallthrough_type"
app = "workflow_engine"

def setup_initial_state(self) -> None:
self.org = self.create_organization(name="test-org")
self.project = self.create_project(organization=self.org)

self.action = Action.objects.create(
type="email",
data={"fallthroughType": FallthroughChoiceType.ACTIVE_MEMBERS},
config={
"target_type": ActionTarget.ISSUE_OWNERS,
"target_identifier": None,
},
)
self.action_no_fallthrough = Action.objects.create(
type="email",
data={},
config={
"target_type": ActionTarget.USER,
"target_identifier": str(self.user.id),
},
)

def test_migration(self) -> None:
fallthrough_action = Action.objects.filter(
data={"fallthrough_type": FallthroughChoiceType.ACTIVE_MEMBERS}
)
assert len(fallthrough_action) == 1

no_fallthrough_action = Action.objects.filter(data={})
assert len(no_fallthrough_action) == 1
Loading