Two small follow-ups for the cleanup-attachments task (#191 ), both deferred out of that PR's original scope for good reason and now unblocked:
Use scheduleS3ObjectDeletion() instead of calling s3.remove() directly. Cleanup task for unreferenced attachments #191 /feat(worker): add cleanup task for unreferenced S3 attachments #195 was built before Create S3 lifecycle configuration #188 existed, so there was nothing to swap to at the time — already flagged as a to-do in feat(worker): delay S3 object deletion instead of removing immediately #197 's PR description. Now that Create S3 lifecycle configuration #188 is merged, cleanup-attachments should get the same grace-period/staleness protection every other deletion path in the codebase has.
Delete the corresponding attachments table row when an orphaned S3 object gets cleaned up, not just the S3 object itself. Found during feat(worker): delay S3 object deletion instead of removing immediately #197 's investigation. Now that attachments is a real, separate table (post-Implement surrogate UUID keys on posts #190 ), leaving the row behind means it just accumulates forever with no S3 object behind it.
Neither is urgent or blocking anything — just tracking so they don't get lost.
Two small follow-ups for the cleanup-attachments task (#191), both deferred out of that PR's original scope for good reason and now unblocked:
Use
scheduleS3ObjectDeletion()instead of callings3.remove()directly. Cleanup task for unreferenced attachments #191/feat(worker): add cleanup task for unreferenced S3 attachments #195 was built before Create S3 lifecycle configuration #188 existed, so there was nothing to swap to at the time — already flagged as a to-do in feat(worker): delay S3 object deletion instead of removing immediately #197's PR description. Now that Create S3 lifecycle configuration #188 is merged, cleanup-attachments should get the same grace-period/staleness protection every other deletion path in the codebase has.Delete the corresponding
attachmentstable row when an orphaned S3 object gets cleaned up, not just the S3 object itself. Found during feat(worker): delay S3 object deletion instead of removing immediately #197's investigation. Now thatattachmentsis a real, separate table (post-Implement surrogate UUID keys on posts #190), leaving the row behind means it just accumulates forever with no S3 object behind it.Neither is urgent or blocking anything — just tracking so they don't get lost.