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
Currently, if a user deletes their account while a job is in the queue, it will continue running even though there may be no way to deliver results. (since they can't log in to get download links)
This is wasteful in times of peak load. We've recently started warning users with multiple accounts, and have seen some examples of people deleting accounts while jobs are running.
Proposed change
The user deletion code currently sets jobs to the user "public" but does not check if jobs are running.
It makes sense to keep some record of jobs for tracking purposes, but ideally, the jobs should be canceled if running (before being changed)
A much longer term solution would be to pair this with "soft deletion", where the user record in the DB was retained, with a new field is_deleted = true that blocks login etc. This would allow auditing of user behavior that is not possible when the entire row is completely removed from the DB.
The text was updated successfully, but these errors were encountered:
Summary
Currently, if a user deletes their account while a job is in the queue, it will continue running even though there may be no way to deliver results. (since they can't log in to get download links)
This is wasteful in times of peak load. We've recently started warning users with multiple accounts, and have seen some examples of people deleting accounts while jobs are running.
Proposed change
The user deletion code currently sets jobs to the user "public" but does not check if jobs are running.
It makes sense to keep some record of jobs for tracking purposes, but ideally, the jobs should be canceled if running (before being changed)
A much longer term solution would be to pair this with "soft deletion", where the user record in the DB was retained, with a new field
is_deleted = true
that blocks login etc. This would allow auditing of user behavior that is not possible when the entire row is completely removed from the DB.The text was updated successfully, but these errors were encountered: