Queue automation project teardown with Oban - #6775
Draft
manelli wants to merge 1 commit into
Draft
Conversation
Contributor
Contributor
AI Review — elixirNo issues found |
Contributor
AI Review — performanceNo issues found |
Contributor
AI Review — securityNo issues found |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Moves full automation-project teardown to an asynchronous Oban job while keeping user and section cleanup synchronous.
Why this is needed
Deleting a full imported course can take several minutes. In one observed run:
The slowdown comes primarily from PostgreSQL foreign-key validation and cascading behavior. Several tables that reference revisions and resources do not have supporting indexes on their foreign-key columns.
When a revision or resource is deleted, PostgreSQL must check the referencing tables for dependent rows. Without an index, this can require sequential table scans. Since a full course contains thousands of resources, those scans may be repeated many times during teardown.
The cost therefore depends not only on the course being deleted, but also on the overall size and state of the database. As shared test tables grow, the scans become longer, causing the same Playwright test to have significantly different teardown times across runs and environments.
Waiting for this work inside the HTTP request caused request timeouts, socket hang-ups, and otherwise successful Playwright runs to report teardown warnings.
What changed
automation_teardownqueue with concurrency1so multiple expensive teardown jobs do not overload PostgreSQL.