feat(aci): create WorkflowFireHistory objects for triggered workflows and update when meeting filters

[cathteng]

We've decided that WorkflowFireHistory will track every time a workflow has been triggered. Note that we only fire actions if subsequent workflow filters are met.

Create these objects for triggered workflows in regular processing and delayed processing.

I added a column (has_fired_actions) to track whether a workflow also met its filters and fired actions -- WorkflowFireHistory objects with has_fired_actions=True should be 1:1 with RuleFireHistory today. Update this column if filters are met (there is 1 filter group per Rule/Workflow during the rollout period, this is not guaranteed in the future).

[codecov]

Codecov Report

Attention: Patch coverage is 98.50746% with 1 line in your changes missing coverage. Please review.

✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
src/sentry/workflow_engine/processors/workflow.py	92.85%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           master   #88775       +/-   ##
===========================================
+ Coverage   42.12%   87.69%   +45.56%     
===========================================
  Files       10062    10093       +31     
  Lines      569227   570890     +1663     
  Branches    22448    22448               
===========================================
+ Hits       239801   500646   +260845     
+ Misses     329018    69836   -259182     
  Partials      408      408               

[saponifi3d]

i'd recommend thinking about the code structure here a little more - how can we make these methods not have side effects? I'm a bit concerned about the increased complexity in process_workflows and the side effects in delayed processor.

[saponifi3d]

next time it'd be a little easier for the review if the event_data rename stuff was split into a separate PR. with this is 1 pr it means i need to try and parse what is just a rename vs the changeset for workflow triggers

[saponifi3d]

this feels like a side effect of fire_actions_for_groups is there another place we could do this? The way i'd structure the code is to evaluate the actions, return the list of actions, then have another method trigger them (no queries or anything in that firing method, just taking a list of actions and calling anything that needs to be fired)

[cathteng]

i agree that ideally this would not be here and preferably would be done beforehand...

logically it belongs right after this in get_groups_to_fire

sentry/src/sentry/workflow_engine/processors/delayed_workflow.py

Line 289 in 14f7a70

passes, _ = evaluate_data_conditions(conditions_to_evaluate, action_match)

i'm not certain if it's possible to nicely slot it in get_groups_to_fire because:

1. WorkflowFireHistory requires the event_id from the GroupEvent
2. we grab the GroupEvents in bulk after exiting from get_groups_to_fire (aka after we figure out which groups we need to fire workflows for)

given this, would it be okay to leave it where it is? i've refactored away other standalone usages save for this one

[ceorourke]

Oof yeah this is tricky, I looked at it for a bit trying to figure out another way and I can't think of anything super clean. You could store filtered_actions in 2 separate variables (since you tack on the results of evaluate_workflows_action_filters and wouldn't want that) and return both along with the corresponding event ids (or just the event ids ins separate vars?) so you can then call create_workflow_fire_histories in process_delayed_workflows, but idk if that's really much better than you have it now.

[saponifi3d]

lgtm - we may want to refactor the delayed processor stuff in the future to avoid the side-effect style updates, but for now 👍