feat(aci): add WorkflowActionGroupStatus table

[cathteng]

Rather than adding a non-nullable Workflow FK column to ActionGroupStatus and backfilling it, we can just create a new table and switch over, eventually dropping ActionGroupStatus.

We need the Workflow in order to enforce workflow frequency per action. In the future, actions may be shared between multiple workflows.

Example:
Workflow A: frequency 5 min

• Action A

Workflow B: frequency 30 min

• Action A

Workflow A should fire Action A every 5 min for a group. Workflow B should fire Action A every 30 min for that same group. If we don't have Workflow on ActionGroupStatus, then both workflows will "share" the most recent firing (read from the same row) and the interval can get wonky. Workflow B may not fire at 30 minute intervals if Workflow A keeps triggering Action A.

[github-actions]

This PR has a migration; here is the generated SQL for src/sentry/workflow_engine/migrations/0066_workflow_action_group_status_table.py

for 0066_workflow_action_group_status_table in workflow_engine

--
-- Create model WorkflowActionGroupStatus
--
CREATE TABLE "workflow_engine_workflowactiongroupstatus" ("id" bigint NOT NULL PRIMARY KEY GENERATED BY DEFAULT AS IDENTITY, "date_updated" timestamp with time zone NOT NULL, "date_added" timestamp with time zone NOT NULL, "action_id" bigint NOT NULL, "group_id" bigint NOT NULL, "workflow_id" bigint NOT NULL, CONSTRAINT "workflow_engine_uniq_workflow_action_group" UNIQUE ("workflow_id", "action_id", "group_id"));
ALTER TABLE "workflow_engine_workflowactiongroupstatus" ADD CONSTRAINT "workflow_engine_work_action_id_b4d629d5_fk_workflow_" FOREIGN KEY ("action_id") REFERENCES "workflow_engine_action" ("id") DEFERRABLE INITIALLY DEFERRED NOT VALID;
ALTER TABLE "workflow_engine_workflowactiongroupstatus" VALIDATE CONSTRAINT "workflow_engine_work_action_id_b4d629d5_fk_workflow_";
ALTER TABLE "workflow_engine_workflowactiongroupstatus" ADD CONSTRAINT "workflow_engine_work_group_id_89305015_fk_sentry_gr" FOREIGN KEY ("group_id") REFERENCES "sentry_groupedmessage" ("id") DEFERRABLE INITIALLY DEFERRED NOT VALID;
ALTER TABLE "workflow_engine_workflowactiongroupstatus" VALIDATE CONSTRAINT "workflow_engine_work_group_id_89305015_fk_sentry_gr";
ALTER TABLE "workflow_engine_workflowactiongroupstatus" ADD CONSTRAINT "workflow_engine_work_workflow_id_8110df1d_fk_workflow_" FOREIGN KEY ("workflow_id") REFERENCES "workflow_engine_workflow" ("id") DEFERRABLE INITIALLY DEFERRED NOT VALID;
ALTER TABLE "workflow_engine_workflowactiongroupstatus" VALIDATE CONSTRAINT "workflow_engine_work_workflow_id_8110df1d_fk_workflow_";
CREATE INDEX CONCURRENTLY "workflow_engine_workflowactiongroupstatus_action_id_b4d629d5" ON "workflow_engine_workflowactiongroupstatus" ("action_id");
CREATE INDEX CONCURRENTLY "workflow_engine_workflowactiongroupstatus_group_id_89305015" ON "workflow_engine_workflowactiongroupstatus" ("group_id");
CREATE INDEX CONCURRENTLY "workflow_engine_workflowactiongroupstatus_workflow_id_8110df1d" ON "workflow_engine_workflowactiongroupstatus" ("workflow_id");

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

⚠️ Parser warning

The parser emitted a warning. Please review your JUnit XML file:

Warning while parsing testcase attributes: Limit of string is 1000 chars, for name, we got 2083 at 1:156310 in /home/runner/work/sentry/sentry/.artifacts/pytest.junit.xml

Additional details and impacted files

@@           Coverage Diff           @@
##           master   #91993   +/-   ##
=======================================
  Coverage   87.86%   87.86%           
=======================================
  Files       10167    10168    +1     
  Lines      582887   582899   +12     
  Branches    22596    22596           
=======================================
+ Hits       512154   512173   +19     
+ Misses      70312    70305    -7     
  Partials      421      421           

[vgrozdanic]

What is the plan for the switchover? Are we going to double write data to both tables for some time?

I am not very familiar with workflows, but don't we need historic data in the new table, which would still require us to do a backfill?

[markstory]

If an account is relocated, do we not want the history of their alert workflows to be preserved?

[cathteng]

hmm this is the workflow engine equivalent to GroupRuleStatus which is excluded from relocation. i'm not entirely sure why, though

[wedamija]

Yeah this is much too much data to relocate, we usually exclude things that are related to groups

[cathteng]

@vgrozdanic I will dual write to both tables and then drop the ActionGroupStatus table. The data in this table is not surfaced anywhere right now and will only be surfaced once we switch over to the new UI for workflow engine, which will not be for some time

[saponifi3d]

lgtm from the workflow engine perspective, pls make sure to get a migration +1 as well :)

[wedamija]

Blocking for now, we're squashing migrations. I'll unblock later today

[wedamija]

Ok, lgtm now. You'll need to recreate your migration on top of the squash. Probably easiest to just delete and recreate it

[getsentry-bot]

PR reverted: 3be3c80