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:157341 in /home/runner/work/sentry/sentry/.artifacts/pytest.junit.xml

Additional details and impacted files

@@             Coverage Diff             @@
##           master   #91993       +/-   ##
===========================================
+ Coverage   36.78%   87.62%   +50.84%     
===========================================
  Files        9662    10361      +699     
  Lines      540758   587575    +46817     
  Branches    22604    22604               
===========================================
+ Hits       198930   514890   +315960     
+ Misses     341407    72264   -269143     
  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

[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