🎨 web-api: empty_trash operation waits until explicitly trashed projects are deleted

[pcrespov]

What do these changes do?

POST /trash:empty now triggers a fire&forget task but ensures that explicitly trashed projects are deleted before responding. This prevents trashed items from still appearing in the list right after the operation, avoiding confusion on the front-end.

This is a compromise between:

1. waiting for all deletions to complete (risks timeouts or client disconnects canceling the operation), and
2. responding immediately after fire-and-forget (items may still appear, misleading users).

NOTE to reviewers: Heuristically, this approach has worked well for me. Nonetheless, if it proves insufficient, we can fall back to option 1 (and then the front-end needs to handle it if it times out).

Related issue/s

• fixes when trash:empty called, hide all entities and then respond #7379

How to test

in place

Dev-ops

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 84.03%. Comparing base (4a3c8fe) to head (3771a5e).
Report is 1 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #7416      +/-   ##
==========================================
- Coverage   86.00%   84.03%   -1.98%     
==========================================
  Files        1638      663     -975     
  Lines       63240    31722   -31518     
  Branches     1131      168     -963     
==========================================
- Hits        54390    26656   -27734     
+ Misses       8528     5008    -3520     
+ Partials      322       58     -264     

Flag	Coverage Δ
integrationtests	65.15% <20.00%> (-0.03%)	⬇️
unittests	87.17% <100.00%> (+0.38%)	⬆️

Components	Coverage Δ
api	∅ <ø> (∅)
pkg_aws_library	∅ <ø> (∅)
pkg_dask_task_models_library	∅ <ø> (∅)
pkg_models_library	∅ <ø> (∅)
pkg_notifications_library	∅ <ø> (∅)
pkg_postgres_database	∅ <ø> (∅)
pkg_service_integration	∅ <ø> (∅)
pkg_service_library	∅ <ø> (∅)
pkg_settings_library	∅ <ø> (∅)
pkg_simcore_sdk	77.30% <ø> (-8.16%)	⬇️
agent	∅ <ø> (∅)
api_server	∅ <ø> (∅)
autoscaling	∅ <ø> (∅)
catalog	∅ <ø> (∅)
clusters_keeper	∅ <ø> (∅)
dask_sidecar	∅ <ø> (∅)
datcore_adapter	∅ <ø> (∅)
director	∅ <ø> (∅)
director_v2	78.49% <ø> (-0.03%)	⬇️
dynamic_scheduler	∅ <ø> (∅)
dynamic_sidecar	89.08% <ø> (-1.04%)	⬇️
efs_guardian	∅ <ø> (∅)
invitations	∅ <ø> (∅)
payments	∅ <ø> (∅)
resource_usage_tracker	∅ <ø> (∅)
storage	∅ <ø> (∅)
webclient	∅ <ø> (∅)
webserver	85.73% <100.00%> (-0.01%)	⬇️

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4a3c8fe...3771a5e. Read the comment docs.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[GitHK]

If you are OK with it. It's fine

[sanderegg]

you can try that. but it looks like a sleep in disguise.
if you have really a big load and the webserver is somehow under the water, that call will take more or less long to respond.