Skip to content

Conversation

@hanifjilani
Copy link

✨ Auto-delete Feature for Trash (Backend + Frontend + Tests)

This PR introduces a complete Auto-delete system for the Trash, integrating both backend logic and frontend behavior while preserving Puter’s existing UX patterns.

Solved the [Feature Request] Auto-delete files from the recycle bin #1658

Backend: Periodic Auto-Delete Service

Added a new TrashAutoDeleteService running every 30 minutes.

For each user, the service:

  • Reads their auto_delete_days preference from kv.

  • Finds files in the user’s Trash folder.

  • Determines which entries are expired based on the configured time window.

  • Emits a trash.auto_delete socket event for each expired file.

  • No files are deleted directly in the backend — it only emits events.

  • The frontend handles deletion using the same existing UX flow as manual deletes.

🖥️ Frontend: Context Menu Integration + Trash Updates

Context Menu Integration

Auto-delete settings are now accessible from three key places:

  • Trash window context menu

  • Trash desktop icon context menu

  • Trash taskbar icon context menu

Users can choose:

  • Disabled

  • 24 hours

  • 7 days

  • 30 days

The selection is stored using Puter’s kv system, allowing the backend service to access user preferences.

Trash UI Reaction

When the backend emits a trash.auto_delete event:

The frontend seamlessly removes the entry from the Trash UI.

This uses the same code path as normal Trash deletions, ensuring consistent behavior.

🧪 Test Coverage

Backend (Vitest)

Added a full unit test suite covering:

  • Single expired item deletion

  • Multiple expired items

  • Disabled preference (0)

  • Missing or malformed timestamps

  • Multiple users with independent Trash folders

  • DB failure logging behavior

  • Periodic scheduling logic

These tests avoid requiring a full Kernel environment by fully mocking DB, helpers, and socket services.

Frontend (Playwright)

Added a Playwright test to verify that the frontend correctly handles socket-emitted auto-delete events.

📁 Summary

This PR adds a complete, fully tested Auto-delete system that:

  • Respects per-user preferences

  • Uses Puter’s existing architecture (KV, services, socket events)

  • Integrates smoothly into the frontend with minimal changes

  • Maintains UX consistency with existing Trash operations

Let me know if you'd like the PR broken into smaller commits or if any part should be refactored!

@CLAassistant
Copy link

CLAassistant commented Dec 2, 2025

CLA assistant check
All committers have signed the CLA.

@hanifjilani
Copy link
Author

Auto_delete_demo1.mp4
Auto_delete_demo2.mp4

@KernelDeimos
Copy link
Contributor

Hello, thanks for submitting this PR. The effort here is appreciated. This will require changes before we're able to merge it into the repo, however. I'm aware that you were originally hoping to have files deleted from backend rather than frontend, and this implementation reflects that. Either the backend or the frontend should be responsible for this, not both; here's why:

We're spending resources (database mostly) iterating over all users and determining which files are expired, to then send a socket event to a user who probably isn't online, expecting them to handle the operation.

We need either proper batching on backend, or a fully-frontend implementation. For this I would actually recommend a fully-frontend implementation because it will be simper to implement and resource consumption grows with user sessions.

Fully Backend Approach

  • Files are also deleted on backend, no socket event
  • The 30-minute "scan all users" interval does not work. You don't know how many users there are, and therefore you cannot make an assumption about how much time is enough for the interval. Also, you probably should not scan all users here either way; better to do so in chunks of 100-or-so users. Parameters like idle time and user chunk size should be managed by ParameterService because they may need to be tuned.

Fully Frontend Approach

  • Interval can correspond to user's configuration. The operation can be expected not to take too long.
  • Schedule and iteration through files are on frontend.

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.

3 participants