feat(aci): Make Workflow.when_condition_group unique

[kcons]

I was going to document this assumption, but it's roughly just as easy to require it and avoid potential weirdness down the road.

[wedamija]

Looks like we just need to rebase this. Just spreading info, you can use ./bin/update-migration to rebase this on top of the latest migration quickly

[wedamija]

This table has 2m rows. I always forget how long it takes to add indexes, but it might be safer to just do this as a post deploy migration to make sure we don't block deploys

[github-actions]

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

for 0103_workflow_when_condition_group_unique in workflow_engine

--
-- Alter field when_condition_group on workflow
--
SET CONSTRAINTS "workflow_engine_work_when_condition_group_11d9ba05_fk_workflow_" IMMEDIATE; ALTER TABLE "workflow_engine_workflow" DROP CONSTRAINT "workflow_engine_work_when_condition_group_11d9ba05_fk_workflow_";
DROP INDEX CONCURRENTLY IF EXISTS "workflow_engine_workflow_when_condition_group_id_11d9ba05";
CREATE UNIQUE INDEX CONCURRENTLY "workflow_engine_workflow_when_condition_group_id_11d9ba05_uniq" ON "workflow_engine_workflow" ("when_condition_group_id");
ALTER TABLE "workflow_engine_workflow" ADD CONSTRAINT "workflow_engine_workflow_when_condition_group_id_11d9ba05_uniq" UNIQUE USING INDEX "workflow_engine_workflow_when_condition_group_id_11d9ba05_uniq";
ALTER TABLE "workflow_engine_workflow" ADD CONSTRAINT "workflow_engine_work_when_condition_group_11d9ba05_fk_workflow_" FOREIGN KEY ("when_condition_group_id") REFERENCES "workflow_engine_dataconditiongroup" ("id") DEFERRABLE INITIALLY DEFERRED NOT VALID;
ALTER TABLE "workflow_engine_workflow" VALIDATE CONSTRAINT "workflow_engine_work_when_condition_group_11d9ba05_fk_workflow_";

[wedamija]

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

for 0103_workflow_when_condition_group_unique in workflow_engine

--
-- Alter field when_condition_group on workflow
--
SET CONSTRAINTS "workflow_engine_work_when_condition_group_11d9ba05_fk_workflow_" IMMEDIATE; ALTER TABLE "workflow_engine_workflow" DROP CONSTRAINT "workflow_engine_work_when_condition_group_11d9ba05_fk_workflow_";
DROP INDEX CONCURRENTLY IF EXISTS "workflow_engine_workflow_when_condition_group_id_11d9ba05";
CREATE UNIQUE INDEX CONCURRENTLY "workflow_engine_workflow_when_condition_group_id_11d9ba05_uniq" ON "workflow_engine_workflow" ("when_condition_group_id");
ALTER TABLE "workflow_engine_workflow" ADD CONSTRAINT "workflow_engine_workflow_when_condition_group_id_11d9ba05_uniq" UNIQUE USING INDEX "workflow_engine_workflow_when_condition_group_id_11d9ba05_uniq";
ALTER TABLE "workflow_engine_workflow" ADD CONSTRAINT "workflow_engine_work_when_condition_group_11d9ba05_fk_workflow_" FOREIGN KEY ("when_condition_group_id") REFERENCES "workflow_engine_dataconditiongroup" ("id") DEFERRABLE INITIALLY DEFERRED NOT VALID;
ALTER TABLE "workflow_engine_workflow" VALIDATE CONSTRAINT "workflow_engine_work_when_condition_group_11d9ba05_fk_workflow_";

Oof, this is going to drop the index first and we'll be uncovered until the unique recreates. I think we should try to structure this so that it creates the unique first, otherwise we might cause some db load if we make queries on this column

[wedamija]

This PR has a migration; here is the generated SQL for src/sentry/workflow_engine/migrations/0103_workflow_when_condition_group_unique.py
for 0103_workflow_when_condition_group_unique in workflow_engine

--
-- Alter field when_condition_group on workflow
--
SET CONSTRAINTS "workflow_engine_work_when_condition_group_11d9ba05_fk_workflow_" IMMEDIATE; ALTER TABLE "workflow_engine_workflow" DROP CONSTRAINT "workflow_engine_work_when_condition_group_11d9ba05_fk_workflow_";
DROP INDEX CONCURRENTLY IF EXISTS "workflow_engine_workflow_when_condition_group_id_11d9ba05";
CREATE UNIQUE INDEX CONCURRENTLY "workflow_engine_workflow_when_condition_group_id_11d9ba05_uniq" ON "workflow_engine_workflow" ("when_condition_group_id");
ALTER TABLE "workflow_engine_workflow" ADD CONSTRAINT "workflow_engine_workflow_when_condition_group_id_11d9ba05_uniq" UNIQUE USING INDEX "workflow_engine_workflow_when_condition_group_id_11d9ba05_uniq";
ALTER TABLE "workflow_engine_workflow" ADD CONSTRAINT "workflow_engine_work_when_condition_group_11d9ba05_fk_workflow_" FOREIGN KEY ("when_condition_group_id") REFERENCES "workflow_engine_dataconditiongroup" ("id") DEFERRABLE INITIALLY DEFERRED NOT VALID;
ALTER TABLE "workflow_engine_workflow" VALIDATE CONSTRAINT "workflow_engine_work_when_condition_group_11d9ba05_fk_workflow_";

Oof, this is going to drop the index first and we'll be uncovered until the unique recreates. I think we should try to structure this so that it creates the unique first, otherwise we might cause some db load if we make queries on this column

We could do this by setting up the constraint like this:

        constraints = [
            UniqueConstraint(
                fields=["when_condition_group_id"],
                name="workflow_engine_workflow_when_condition_group_id_11d9ba05_uniq",
        ]

and generating the migration, then setting db_index=False and generating that migration, then shoving operations in order into database_operations in SeparateDatabaseAndState in your current migration, and putting the current operations in the state_operations part

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@             Coverage Diff              @@
##           master   #103768       +/-   ##
============================================
+ Coverage   66.03%    80.62%   +14.58%     
============================================
  Files        9271      9279        +8     
  Lines      395607    396080      +473     
  Branches    25247     25247               
============================================
+ Hits       261253    319343    +58090     
+ Misses     133894     76277    -57617     
  Partials      460       460               

[github-actions]

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

for 0103_add_unique_constraint in workflow_engine

--
-- Custom state/database change combination
--
CREATE UNIQUE INDEX CONCURRENTLY "workflow_engine_workflow_when_condition_group_id_11d9ba05_uniq" ON "workflow_engine_workflow" ("when_condition_group_id");
ALTER TABLE "workflow_engine_workflow" ADD CONSTRAINT "workflow_engine_workflow_when_condition_group_id_11d9ba05_uniq" UNIQUE USING INDEX "workflow_engine_workflow_when_condition_group_id_11d9ba05_uniq";
SET CONSTRAINTS "workflow_engine_work_when_condition_group_11d9ba05_fk_workflow_" IMMEDIATE; ALTER TABLE "workflow_engine_workflow" DROP CONSTRAINT "workflow_engine_work_when_condition_group_11d9ba05_fk_workflow_";
DROP INDEX CONCURRENTLY IF EXISTS "workflow_engine_workflow_when_condition_group_id_11d9ba05";
ALTER TABLE "workflow_engine_workflow" ADD CONSTRAINT "workflow_engine_work_when_condition_group_11d9ba05_fk_workflow_" FOREIGN KEY ("when_condition_group_id") REFERENCES "workflow_engine_dataconditiongroup" ("id") DEFERRABLE INITIALLY DEFERRED NOT VALID;
ALTER TABLE "workflow_engine_workflow" VALIDATE CONSTRAINT "workflow_engine_work_when_condition_group_11d9ba05_fk_workflow_";

[wedamija]

I was thinking that the final state could actually have unique=True here and not have the UniqueConstraint, just to use those as the db operations. But tbh it doesn't really matter which way we do it as long as both exist, so this lgtm