You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ticket is understood, and QA has been contacted (if the ticket has a QA label).
Changes for 1685 revised migration 0331_merge_service_api. Before the revision, the migration's "upgrade" function copied all rows in the "service_inbound_api" table to other tables, but it did not drop the table. However, the "downgrade" action contains code to create the table. If it already exists (because it didn't get dropped) this will cause an error during a downgrade. The table still exists in some of our environments even though it is no longer in app/models.py. It exists in Prod with zero rows.
Although the table is not in app/models.py, there is a bit of easily removable tech debt associated with it in the form of a schema and associated tests.
Steps to Reproduce
You would have to rollback over 30 migrations to trigger this problem, which is not going to happen, but you can observe that the "service_inbound_api" table still exists in Prod.
No workaround is necessary.
Impact/Urgency
This is low impact, low urgency, but also a quick fix.
Engineering Checklist
In AWS, manually drop the table "service_inbound_api" from any environment in which the table is present
In app/service/service_callback_api_schema.py, delete "update_service_inbound_api_schema"
Delete associated tests in tests/app/service/test_schema.py
Expected Behavior
-[ ] When I run the unit tests, they all pass.
-[ ] When I deploy the app to an environment after this table is removed, then the app starts without errors and the regression passes.
Additional Info & Resources
The text was updated successfully, but these errors were encountered:
Description
Changes for 1685 revised migration 0331_merge_service_api. Before the revision, the migration's "upgrade" function copied all rows in the "service_inbound_api" table to other tables, but it did not drop the table. However, the "downgrade" action contains code to create the table. If it already exists (because it didn't get dropped) this will cause an error during a downgrade. The table still exists in some of our environments even though it is no longer in app/models.py. It exists in Prod with zero rows.
Although the table is not in app/models.py, there is a bit of easily removable tech debt associated with it in the form of a schema and associated tests.
Steps to Reproduce
You would have to rollback over 30 migrations to trigger this problem, which is not going to happen, but you can observe that the "service_inbound_api" table still exists in Prod.
No workaround is necessary.
Impact/Urgency
This is low impact, low urgency, but also a quick fix.
Engineering Checklist
Expected Behavior
-[ ] When I run the unit tests, they all pass.
-[ ] When I deploy the app to an environment after this table is removed, then the app starts without errors and the regression passes.
Additional Info & Resources
The text was updated successfully, but these errors were encountered: