Skip to content

fix(ACI): Migrate fallthroughType to fallthrough_type #103764

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 5 commits into
base: master
Choose a base branch
from
Open

fix(ACI): Migrate fallthroughType to fallthrough_type #103764

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
1575750
fix(ACI): Migrate fallthroughType to fallthrough_type
ceorourke Nov 20, 2025
67d41ba
rebase
ceorourke Nov 24, 2025
831f987
make post deployment
ceorourke Nov 24, 2025
9202d69
update test, update how we check for fallthrough type
ceorourke Nov 24, 2025
ecc1041
update hint to use correct table
ceorourke Nov 24, 2025
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
View file
Open in desktop
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: 0103_add_unique_constraint
workflow_engine: 0104_action_data_fallthrough_type
47 changes: 47 additions & 0 deletions src/sentry/workflow_engine/migrations/0104_action_data_fallthrough_type.py
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,47 @@
# Generated by Django 5.2.8 on 2025-11-24 19:57

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 "fallthroughType" in action.data:
new_data = action.data.copy()
del new_data["fallthroughType"]
new_data["fallthrough_type"] = action.data["fallthroughType"]
action.data = new_data
action.save()


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 = True

Comment on lines +27 to +36
Copy link

@sentry sentry bot Nov 24, 2025

Choose a reason for hiding this comment

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

Bug: The EmailDataBlob dataclass instantiation will fail after migration due to unexpected keyword arguments from action_data.
Severity: CRITICAL | Confidence: High

🔍 Detailed Analysis

After migration 0104_action_data_fallthrough_type.py runs, the EmailIssueAlertHandler.get_additional_fields() method will attempt to instantiate EmailDataBlob using EmailDataBlob(**action_data). The action_data dictionary will contain keys such as targetType, targetIdentifier, uuid, and id in addition to fallthrough_type. Since the EmailDataBlob dataclass only defines fallthrough_type, passing these unexpected keyword arguments will raise a TypeError (e.g., __init__() got an unexpected keyword argument 'targetType'). This will lead to a server crash whenever an email action with target_type == ActionTarget.ISSUE_OWNERS is processed.

💡 Suggested Fix

Modify the EmailIssueAlertHandler.get_additional_fields() method to filter action_data before instantiating EmailDataBlob, ensuring only fallthrough_type is passed. Alternatively, update the EmailDataBlob dataclass to include all relevant fields from action_data.

🤖 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/0104_action_data_fallthrough_type.py#L27-L36

Potential issue: After migration `0104_action_data_fallthrough_type.py` runs, the
`EmailIssueAlertHandler.get_additional_fields()` method will attempt to instantiate
`EmailDataBlob` using `EmailDataBlob(**action_data)`. The `action_data` dictionary will
contain keys such as `targetType`, `targetIdentifier`, `uuid`, and `id` in addition to
`fallthrough_type`. Since the `EmailDataBlob` dataclass only defines `fallthrough_type`,
passing these unexpected keyword arguments will raise a `TypeError` (e.g., `__init__()
got an unexpected keyword argument 'targetType'`). This will lead to a server crash
whenever an email action with `target_type == ActionTarget.ISSUE_OWNERS` is processed.

Did we get this right? 👍 / 👎 to inform future reviews.
Reference ID: 3286846

Copy link
Member Author

@ceorourke ceorourke Nov 24, 2025

Choose a reason for hiding this comment

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

This seems out of scope and kinda unrelated - I updated EmailDataBlob in the other PR to use fallthrough_type instead of fallthroughType https://github.com/getsentry/sentry/blob/master/src/sentry/workflow_engine/typings/notification_action.py#L737-L743, if it's missing other kwargs that's a different problem.

dependencies = [
("workflow_engine", "0103_add_unique_constraint"),
]

operations = [
migrations.RunPython(
code=migrate_fallthrough_type,
reverse_code=migrations.RunPython.noop,
hints={"tables": ["workflow_engine_action"]},
),
]
40 changes: 40 additions & 0 deletions tests/sentry/workflow_engine/migrations/test_0104_action_data_fallthrough_type.py
View file
Open in desktop
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 = "0103_add_unique_constraint"
migrate_to = "0104_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