[Team Deletions] effective scheduling - #6615
Conversation
aerosol
changed the title
aerosol
changed the title
| (not is_nil(s.id) and | ||
| s.status in [^Subscription.Status.deleted(), ^Subscription.Status.paused()] and | ||
| s.paddle_plan_id != "free_10k" and s.next_bill_date < ^today), | ||
| where: |
There was a problem hiding this comment.
Here we leave the existing DeletionSchedule rows alone even if the team state has changed since it was created. Once the DeletionSchedule row has been inserted, it's still possible for CS to extend someone's trial, add an enterprise plan or add a manual lock. So the pending deletion schedules will get out of sync with team billing states.
I think it's fine for them to get out of sync as long as the email and deletion worker re-check everything and reconcile the deletion table as needed. I assume you've already thought of this but I just wanted to double check :)
There was a problem hiding this comment.
I only thought of deletion snooze, not the fact that CS would want to extend the trial. Why would anyone want to add a lock though? (to a team that implicitly doesn't accept traffic anymore?). Having a look if there are other team states we need to watch out for. This is starting to cry for some event-driven fsm transitions.
There was a problem hiding this comment.
Can't wrap my head around this yet, leaving it up for discussion at https://3.basecamp.com/5308029/buckets/44692882/messages/10216872798#__recording_10236982367
23479fc to
14f4f0b
Compare
…s-deletions-intervals
2 participants
On top of #6613 this PR implements the core deletion eligibility logic including the background worker (tested but kept inactive for now).
A daily worker seeks for eligible teams and bulk-inserts
team_deletion_schedulesrows.Additional Paddle webhooks checks are planted to cancel any pending deletions upon subscription renewal.
Schema/migration change (deleted->completed rename) backported to previous branches in the stack.