Skip to content

Conversation

@ceorourke
Copy link
Member

Follow up to #103764 - once the migration is complete we can remove the temporary logic to support the incorrect case.

@ceorourke ceorourke requested review from a team as code owners November 25, 2025 19:20
@github-actions github-actions bot added the Scope: Backend Automatically applied to PRs that change backend components label Nov 25, 2025
@codecov
Copy link

codecov bot commented Nov 25, 2025

❌ 1 Tests Failed:

Tests completed Failed Passed Skipped
195 1 194 40
View the top 1 failed test(s) by shortest run time
tests.sentry.workflow_engine.migrations.test_0104_action_data_fallthrough_type.TestActionDataFallthroughType::test_migration
Stack Traces | 2.58s run time
#x1B[1m#x1B[.../workflow_engine/migrations/test_0104_action_data_fallthrough_type.py#x1B[0m:16: in setup_initial_state
    self.action = Action.objects.create(
#x1B[1m#x1B[.../sentry/silo/base.py#x1B[0m:159: in override
    return original_method(*args, **kwargs)
#x1B[1m#x1B[31m.venv/lib/python3.13.../db/models/manager.py#x1B[0m:87: in manager_method
    return getattr(self.get_queryset(), name)(*args, **kwargs)
#x1B[1m#x1B[.../sentry/silo/base.py#x1B[0m:159: in override
    return original_method(*args, **kwargs)
#x1B[1m#x1B[31m.venv/lib/python3.13.../db/models/query.py#x1B[0m:665: in create
    obj.save(force_insert=True, using=self.db)
#x1B[1m#x1B[.../sentry/silo/base.py#x1B[0m:159: in override
    return original_method(*args, **kwargs)
#x1B[1m#x1B[31m.venv/lib/python3.13.../db/models/base.py#x1B[0m:902: in save
    self.save_base(
#x1B[1m#x1B[.../sentry/silo/base.py#x1B[0m:159: in override
    return original_method(*args, **kwargs)
#x1B[1m#x1B[31m.venv/lib/python3.13.../db/models/base.py#x1B[0m:988: in save_base
    pre_save.send(
#x1B[1m#x1B[.../testutils/pytest/stale_database_reads.py#x1B[0m:101: in send
    return old_send(self, sender, **named)
#x1B[1m#x1B[31m.venv/lib/python3.13.../django/dispatch/dispatcher.py#x1B[0m:189: in send
    response = receiver(signal=self, sender=sender, **named)
#x1B[1m#x1B[.../workflow_engine/models/action.py#x1B[0m:190: in enforce_config_schema
    raise ValidationError(f"Invalid config: {e.message}")
#x1B[1m#x1B[31mE   jsonschema.exceptions.ValidationError: Invalid config: Additional properties are not allowed ('fallthroughType' was unexpected)#x1B[0m

To view more test analytics, go to the Test Analytics Dashboard
📋 Got 3 mins? Take this short survey to help us improve Test Analytics.

@ceorourke ceorourke requested a review from a team as a code owner November 25, 2025 19:32
action_data["fallthrough_type"] = action.data["fallthroughType"]

blob = EmailDataBlob(**action_data)
blob = EmailDataBlob(**action.data)
Copy link

Choose a reason for hiding this comment

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

Bug: Removing fallthroughType backward compatibility before post-deployment migration causes TypeError.
Severity: CRITICAL | Confidence: High

🔍 Detailed Analysis

The code removes backward compatibility logic for the fallthroughType field before its corresponding post-deployment migration has run. This causes a TypeError crash when EmailDataBlob(**action.data) is called with existing Action records that still contain fallthroughType (camelCase) in their action.data, as EmailDataBlob only accepts fallthrough_type (snake_case). This affects email notifications to issue owners immediately after deployment and before the migration 0104_action_data_fallthrough_type.py completes.

💡 Suggested Fix

Reinstate the backward compatibility logic to convert fallthroughType to fallthrough_type before passing action.data to EmailDataBlob, or ensure the migration runs before the code deployment.

🤖 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/notifications/notification_action/issue_alert_registry/handlers/email_issue_alert_handler.py#L54

Potential issue: The code removes backward compatibility logic for the `fallthroughType`
field before its corresponding post-deployment migration has run. This causes a
`TypeError` crash when `EmailDataBlob(**action.data)` is called with existing `Action`
records that still contain `fallthroughType` (camelCase) in their `action.data`, as
`EmailDataBlob` only accepts `fallthrough_type` (snake_case). This affects email
notifications to issue owners immediately after deployment and before the migration
`0104_action_data_fallthrough_type.py` completes.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Scope: Backend Automatically applied to PRs that change backend components

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants