Skip to content
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.

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

♻️ feat(workflow_engine): issue alert action migration util for slack #83123

Merged
merged 8 commits into from
Jan 14, 2025

Conversation

iamrajjoshi
Copy link
Member

@iamrajjoshi iamrajjoshi commented Jan 8, 2025

this pr starts the implementation of migration util for issue alert migration to aci.

added some comments to the code for context.

replaces: #82505

@github-actions github-actions bot added the Scope: Backend Automatically applied to PRs that change backend components label Jan 8, 2025
return build_slack_data_blob(action).__dict__
# # Otherwise, we can just return the action data as is, removing the keys we don't want to save
else:
return {
Copy link
Member Author

Choose a reason for hiding this comment

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

popping keys we save elsewhere or don't want to save

@iamrajjoshi iamrajjoshi requested a review from a team January 8, 2025 21:27
@iamrajjoshi iamrajjoshi marked this pull request as ready for review January 8, 2025 21:27
Copy link

codecov bot commented Jan 8, 2025

Codecov Report

Attention: Patch coverage is 93.41317% with 11 lines in your changes missing coverage. Please review.

✅ All tests successful. No failed tests found.

Files with missing lines Patch % Lines
...try/workflow_engine/typings/notification_action.py 91.54% 6 Missing ⚠️
...gine/migration_helpers/test_migrate_rule_action.py 92.85% 5 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master   #83123      +/-   ##
==========================================
- Coverage   87.48%   87.48%   -0.01%     
==========================================
  Files        9406     9409       +3     
  Lines      537270   537437     +167     
  Branches    21158    21158              
==========================================
+ Hits       470047   470188     +141     
- Misses      66866    66892      +26     
  Partials      357      357              

Copy link
Member

@ceorourke ceorourke left a comment

Choose a reason for hiding this comment

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

left some nits but overall lgtm

integration_id_key = ACTION_TYPE_TO_INTEGRATION_ID_KEY.get(action_type)
if integration_id_key is None:
# we should always have an integration id key if target type is specific
# TODO(iamrajjoshi): Should we fail loudly here?
Copy link
Contributor

Choose a reason for hiding this comment

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

I think it depends on how this method is being used to migrate a rule. I'd think of this as flow control, if we want to continue creating the new action / workflow then we should just log and continue like you have. If we want to stop creation of the workflow because it will be malformed, we should throw an error to stop the migration (or handle the issue in another area)

Copy link
Member Author

Choose a reason for hiding this comment

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

talked with cathy, we will log the error and continue to build actions that we can. actions that we store in Rule that are malformed don't fire in the first place and we don't have any system that heals these actions, so we just won't migrate them.

Comment on lines 125 to 128
integration_id=integration_id,
target_identifier=target_identifier,
target_display=target_display,
target_type=target_type,
Copy link
Contributor

Choose a reason for hiding this comment

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

would we want to create the action if any of these weren't set? (given the current code flow, that could be a possibility)

# FWIW, we don't use target type for issue alerts
target_type = ACTION_TYPE_TO_TARGET_TYPE_RULE_REGISTRY.get(action_type)

if target_type == ActionTarget.SPECIFIC:
Copy link
Contributor

Choose a reason for hiding this comment

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

since we're not using the target_type could we just say if the target type isn't set to specific, then continue or throw an exception? i think that might help make this code a little more readable since we could dedent a lot of it, but i'm not sure if we want to since the notification_action can be created w/o these properties.

src/sentry/workflow_engine/typings/notification_action.py Outdated Show resolved Hide resolved
Copy link
Member

@cathteng cathteng left a comment

Choose a reason for hiding this comment

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

the logic looks good, i just have a few suggestions for organization

# Get the target_identifier if it exists
target_identifier_key = ACTION_TYPE_TO_TARGET_IDENTIFIER_KEY.get(action_type)
if target_identifier_key is not None:
target_identifier = action.get(target_identifier_key)
Copy link
Member

Choose a reason for hiding this comment

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

i think target_identifier might need to be initialized outside of this if block, similarly with target_display below

Comment on lines 48 to 53
not in [
ACTION_TYPE_TO_INTEGRATION_ID_KEY.get(action_type),
ACTION_TYPE_TO_TARGET_IDENTIFIER_KEY.get(action_type),
ACTION_TYPE_TO_TARGET_DISPLAY_KEY.get(action_type),
*EXCLUDED_ACTION_DATA_KEYS,
]
Copy link
Member

Choose a reason for hiding this comment

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

do we remove these because these are used in metric alerts?

Copy link
Member Author

Choose a reason for hiding this comment

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

we remove them b/c we already store them in some other field. i want to keep the blob as small as possible, containing extra context that we need to send a notification.

src/sentry/workflow_engine/typings/notification_action.py Outdated Show resolved Hide resolved
Copy link
Member

@cathteng cathteng left a comment

Choose a reason for hiding this comment

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

some more thoughts 🤔

try:
translator_class = issue_alert_action_translator_registry.get(registry_id)
translator = translator_class()
except KeyError:
Copy link
Member

Choose a reason for hiding this comment

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

the Registry class will throw NoRegistrationExists error if the key doesn't exist


try:
translator_class = issue_alert_action_translator_registry.get(registry_id)
translator = translator_class()
Copy link
Member

Choose a reason for hiding this comment

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

maybe you can pass in the action to the translator class so you can do this in one go

target_display = None
if translator.target_display_key:
    target_display = action.get(translator.target_display_key)

becomes

target_display = translator.target_display_key

Copy link
Member

@cathteng cathteng left a comment

Choose a reason for hiding this comment

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

see big comment

Comment on lines +62 to +69
notification_action = Action(
type=translator.action_type,
data=translator.get_sanitized_data(),
integration_id=translator.integration_id,
target_identifier=translator.target_identifier,
target_display=translator.target_display,
target_type=translator.target_type,
)
Copy link
Member

Choose a reason for hiding this comment

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

so clean 😻

src/sentry/workflow_engine/typings/notification_action.py Outdated Show resolved Hide resolved
@iamrajjoshi iamrajjoshi marked this pull request as draft January 14, 2025 19:24
@iamrajjoshi iamrajjoshi marked this pull request as ready for review January 14, 2025 19:24
@iamrajjoshi iamrajjoshi enabled auto-merge (squash) January 14, 2025 19:24
@iamrajjoshi iamrajjoshi merged commit ca71de7 into master Jan 14, 2025
49 checks passed
@iamrajjoshi iamrajjoshi deleted the raj/issue-alert-migration-helper-slack branch January 14, 2025 19:52
@github-actions github-actions bot locked and limited conversation to collaborators Jan 30, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Scope: Backend Automatically applied to PRs that change backend components
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants