Skip to content

Conversation

@stsewd
Copy link
Member

@stsewd stsewd commented Oct 30, 2025

Closes #10040

@stsewd stsewd marked this pull request as ready for review October 30, 2025 19:16
@stsewd stsewd requested a review from a team as a code owner October 30, 2025 19:16
@stsewd stsewd requested a review from agjohnson October 30, 2025 19:16
"""
task_log = log.bind(model_name=model_name, object_pk=pk, user_id=user_id)
lock_id = f"{self.name}-{model_name}-{pk}-lock"
lock_expire = 60 * 60 * 2 # 2 hours
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe one hour is fine? or less...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I think it's not super important.

@stsewd stsewd requested a review from Copilot October 30, 2025 23:22
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR converts project and organization deletion from synchronous to asynchronous operations to avoid request timeouts when deleting large objects. The changes introduce a new Celery task and view mixin to queue deletions for background processing.

Key Changes:

  • Created AsyncDeleteViewWithMessage mixin to queue deletions asynchronously
  • Added delete_object Celery task with locking to handle async deletions
  • Enhanced set_change_reason to support user tracking outside request context

Reviewed Changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.

Show a summary per file
File Description
readthedocs/core/tasks.py Adds delete_object Celery task to asynchronously delete database objects with locking mechanism
readthedocs/core/mixins.py Introduces AsyncDeleteViewWithMessage mixin that queues deletion tasks instead of directly deleting objects
readthedocs/core/history.py Extends set_change_reason to accept optional user parameter for tracking deletions outside request context
readthedocs/projects/views/private.py Updates ProjectDelete view to use async deletion with updated success message
readthedocs/organizations/views/private.py Updates DeleteOrganization view to use async deletion with updated success message

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copy link
Member

@humitos humitos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. Should we make a distinction in the UI when the project/organization is being deleted? It will be weird that you click on "Delete project", get redirected to the dashboard home page listing all your projects, and you still see the project there.

Is there an easy way to implement a UI distinction here?

:param user_id: The ID of the user performing the deletion.
Just for logging purposes.
"""
task_log = log.bind(model_name=model_name, object_pk=pk, user_id=user_id)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are you using task_log here instead of log as we are doing in all the other places?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

log is a global variable and python gets confused with the scope, raising an error that the variable is unbound.

"""
task_log = log.bind(model_name=model_name, object_pk=pk, user_id=user_id)
lock_id = f"{self.name}-{model_name}-{pk}-lock"
lock_expire = 60 * 60 * 2 # 2 hours
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I think it's not super important.

@stsewd
Copy link
Member Author

stsewd commented Nov 3, 2025

Should we make a distinction in the UI when the project/organization is being deleted? It will be weird that you click on "Delete project", get redirected to the dashboard home page listing all your projects, and you still see the project there.

See #10040 (comment). We can, but we will need to change all querysets to ignore those objects... I guess we could do it incrementally, but hopefully the message "queued for deletion" hints users that the project is being deleted on the background.

@stsewd stsewd merged commit f787d93 into main Nov 3, 2025
7 checks passed
@stsewd stsewd deleted the async-delete branch November 3, 2025 15:52
@humitos
Copy link
Member

humitos commented Nov 3, 2025

we will need to change all querysets to ignore those objects

Yeah, this would be a ton of work. I don't think we want to ignore these projects, but at least just adding a visual differentiation in the UI.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Project: Deleting a project cascades computations that time out

3 participants