Clean up degenerate deployments

[WeiQuan0605]

With the fix, job finalized-degenerate-deployment only considers active deployments.status.reason will not have DEGENERATEanymore. The old DEGENERATE records should be cleaned up through DB migration.

• I have reviewed the contributing guide

• I have viewed, signed, and submitted the Contributor License Agreement

• I have made this pull request to the main branch

• I have run all the unit tests using bundle exec rake

• I have run CF Acceptance Tests

[svkrieger]

As far as I could see the DEGENERATE state will not appear anymore.
Actually it should have never been introduced, so it's good that we clean it up now.
Initially the DEGENERATE state was meant for deployments, which were "half way created" because the process was not created in one transaction together with the deployment. But this has been fixed already.
So apps using deployments, be it a new app or a running app, will always have a process guid already, which makes this state obsolete.

A small test for the migration, which creates a few deployments with state DEGENERATE and checks that the migration deletes them would be nice, because we get early feedback whether the migration runs on all supported DBs.

[svkrieger]

LGTM

[ChrisMcGowan]

As far as I could see the DEGENERATE state will not appear anymore. Actually it should have never been introduced, so it's good that we clean it up now. Initially the DEGENERATE state was meant for deployments, which were "half way created" because the process was not created in one transaction together with the deployment. But this has been fixed already. So apps using deployments, be it a new app or a running app, will always have a process guid already, which makes this state obsolete.

A small test for the migration, which creates a few deployments with state DEGENERATE and checks that the migration deletes them would be nice, because we get early feedback whether the migration runs on all supported DBs.

@svkrieger & @WeiQuan0605 - curious on your testing if you ran into this. In prod today we migrated from cf-deployment v35.3 to v35.4 which moved CAPI from 0.167.0 to 0.168.0 which has this change. We have not filed a Issue yet but probably will soon.

The migration script when it fires runs into the following error:

[2024-01-09 18:20:21+0000] Sequel::ForeignKeyConstraintViolation: PG::ForeignKeyViolation: ERROR:  update or delete on table "deployments" violates foreign key constraint "fk_deployment_processes_deployment_guid" on table "deployment_processes" (Sequel::ForeignKeyConstraintViolation)
[2024-01-09 18:20:21+0000] DETAIL:  Key (guid)=(<app guid scrubbed>) is still referenced from table "deployment_processes".

We have over 31K rows in deployments and by count over 7,500 rows marked for delete with this migration script. Going back in this repo we found the initial framework for this in this migration script from here back in 2018.

This appears to be deleting the parent record but not the child records since a "cascade" delete is not taking place.

Can you advise on your testing why you did not get the errors ?

For reference we are using Postgres 12.14 on Amazon RDS

Thanks

[johha]

@ChrisMcGowan Looks like something we missed 😞
I created #3592 and will adjust the release notes accordingly

[ChrisMcGowan]

Thank you @johha