Skip to content

ref(aci): Big delayed_workflow refactor #93569

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

Merged
merged 4 commits into from
Jun 18, 2025
Merged

ref(aci): Big delayed_workflow refactor #93569

merged 4 commits into from
Jun 18, 2025

Conversation

kcons
Copy link
Member

@kcons kcons commented Jun 13, 2025

Still some weirdness here, but the aim is to bundle up all of the redis-derived data (TODO: better name for it) and pass that around as an immutable fact rather than obscuring things by having various dicts being passed everywhere.

@github-actions github-actions bot added the Scope: Backend Automatically applied to PRs that change backend components label Jun 13, 2025
@kcons kcons marked this pull request as ready for review June 16, 2025 16:51
@kcons kcons requested a review from a team as a code owner June 16, 2025 16:51
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.

I think it looks good but idk if we want to address removing bad data from the buffer in this PR

"Failed to parse workflow event data",
extra={"key": key, "value": value, "error": str(e)},
)
raise ValueError(f"Failed to parse Redis data: {str(e)}") from e
Copy link
Member

Choose a reason for hiding this comment

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

even if one of the items in Redis is added incorrectly, should we still proceed with processing or error out on the whole batch?

maybe we should remove it from the batch if we're not going to process it?

Copy link
Member Author

Choose a reason for hiding this comment

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

Thank you for flagging this; I wanted to revisit this before sending it for review, but then the weekend came and I forgot.
Yeah, I agree that log.exception and continue is probably our preferred approach here. May even make it a required parameter to make the callsites obvious about it.

Comment on lines +497 to +545
in event_data.trigger_group_to_dcg_model[
DataConditionHandler.Group.WORKFLOW_TRIGGER
]
):
workflow_triggers.add(dcg)
elif (
dcg.id
in trigger_group_to_dcg_model[DataConditionHandler.Group.ACTION_FILTER]
in event_data.trigger_group_to_dcg_model[
DataConditionHandler.Group.ACTION_FILTER
]
Copy link
Member

Choose a reason for hiding this comment

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

something i noticed about my own code is that we could probably just do set intersection to figure out which ones are workflow triggers and which ones are action filters

Copy link

codecov bot commented Jun 17, 2025

Codecov Report

Attention: Patch coverage is 80.73394% with 42 lines in your changes missing coverage. Please review.

✅ All tests successful. No failed tests found.

Files with missing lines Patch % Lines
...orkflow_engine/processors/test_delayed_workflow.py 68.13% 29 Missing ⚠️
...try/workflow_engine/processors/delayed_workflow.py 89.76% 13 Missing ⚠️
Additional details and impacted files
@@             Coverage Diff             @@
##           master   #93569       +/-   ##
===========================================
+ Coverage   37.97%   83.21%   +45.24%     
===========================================
  Files        9774    10333      +559     
  Lines      552441   596806    +44365     
  Branches    23194    23194               
===========================================
+ Hits       209769   496612   +286843     
+ Misses     342213    99735   -242478     
  Partials      459      459               

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.

lgtm :shipit:

Comment on lines +366 to +367
workflow_id = event_data.dcg_to_workflow.get(dcg.id)
workflow_env = workflows_to_envs[workflow_id] if workflow_id else None
Copy link
Member

Choose a reason for hiding this comment

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

nice 🙏


logger.info(
"delayed_workflow.workflows",
extra={
"data": workflow_event_dcg_data,
"workflows": set(dcg_to_workflow.values()),
"data": redis_data,
Copy link
Member

Choose a reason for hiding this comment

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

i had to google if this would log nicely and it will! yay

@kcons kcons merged commit 018bd22 into master Jun 18, 2025
63 checks passed
@kcons kcons deleted the kcons/maybe branch June 18, 2025 20:49
andrewshie-sentry pushed a commit that referenced this pull request Jun 19, 2025
The core aim here is to bundle up all of the
redis-derived data (still needs another naming pass) and pass that around as an
immutable fact rather than obscuring things by having various dicts
being passed everywhere.
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.

2 participants