🎨 Makes removal of long running tasks faster

[GitHK]

What do these changes do?

Users of lrt_api no longer have to deal with waiting for the removal of a task. Once marked for removal, it no longer appears to them.

The only side effect this causes is that unique long running tasks, which are used by the dynamic-sidecar only cannot be restarted immediately. This should not have an impact, but I can easily address the issue if it appars.

Related issue/s

• fixes Decoupling Task Removal to Improve get_task_result Performance #8340

How to test

Dev-ops

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 87.88%. Comparing base (62565ba) to head (fdf2f2c).
⚠️ Report is 1 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #8350      +/-   ##
==========================================
+ Coverage   87.86%   87.88%   +0.01%     
==========================================
  Files        1945     1945              
  Lines       75630    75623       -7     
  Branches     1321     1322       +1     
==========================================
+ Hits        66456    66459       +3     
+ Misses       8776     8767       -9     
+ Partials      398      397       -1     

Flag	Coverage Δ
integrationtests	63.92% <ø> (-0.02%)	⬇️
unittests	86.55% <100.00%> (+0.01%)	⬆️

Components	Coverage Δ
pkg_aws_library	93.59% <ø> (ø)
pkg_celery_library	84.71% <ø> (ø)
pkg_dask_task_models_library	79.33% <ø> (ø)
pkg_models_library	93.09% <ø> (ø)
pkg_notifications_library	85.20% <ø> (ø)
pkg_postgres_database	87.95% <ø> (ø)
pkg_service_integration	70.19% <ø> (ø)
pkg_service_library	71.75% <100.00%> (+0.01%)	⬆️
pkg_settings_library	90.19% <ø> (ø)
pkg_simcore_sdk	84.99% <ø> (ø)
agent	93.53% <ø> (ø)
api_server	91.94% <ø> (ø)
autoscaling	95.77% <ø> (ø)
catalog	92.36% <ø> (ø)
clusters_keeper	99.13% <ø> (ø)
dask_sidecar	92.37% <ø> (+0.56%)	⬆️
datcore_adapter	97.94% <ø> (ø)
director	75.81% <ø> (-0.09%)	⬇️
director_v2	90.86% <ø> (-0.16%)	⬇️
dynamic_scheduler	96.27% <ø> (ø)
dynamic_sidecar	90.46% <ø> (ø)
efs_guardian	89.62% <ø> (ø)
invitations	91.44% <ø> (ø)
payments	92.61% <ø> (ø)
resource_usage_tracker	92.24% <ø> (-0.06%)	⬇️
storage	86.83% <ø> (+0.16%)	⬆️
webclient	∅ <ø> (∅)
webserver	87.99% <ø> (+0.04%)	⬆️

---

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 62565ba...fdf2f2c. 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.

[mergify]

🧪 CI Insights

Here's what we observed from your CI run for fdf2f2c.

✅ Passed Jobs With Interesting Signals

Pipeline	Job	Signal	Health on master	Retries	🔍 CI Insights	📄 Logs
CI	system-tests	Base branch is broken, but the job passed. Looks like this might be a real fix 💪		0	View	View

[sanderegg]

thanks! looking forward

[bisgaard-itis]

Thanks for the effort. Just a few suggestions/comments to take into consideration from my side.

[pcrespov]

thx

Please check manually that the creation of projects does not get delayed anymore in the /results as described in the original gh issue.

[bisgaard-itis]

Thanks a lot

[GitHK]

@Mergifyio queue

[mergify]

queue

🛑 Configuration not compatible with a branch protection setting

The branch protection setting Require branches to be up to date before merging is not compatible with max_parallel_checks>1, queue_conditions != merge_conditions and must be unset.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
1 Accepted issue

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

See analysis details on SonarQube Cloud