gsadmin/sencho
1
0
Fork 0
mirror of https://github.com/Studio-Saelix/sencho.git synced 2026-08-10 10:49:35 +00:00
Code Issues Packages Projects Releases Wiki Activity

fix(fleet): refresh prune reclaimable estimate after successful run (#1675)

Browse Source 
* fix(fleet): refresh prune reclaimable estimate after successful run

The live estimate only re-ran when targets or scope changed, so the
toolbar and per-node reclaimable figures stayed stale after a real prune.
Invalidate via estimateEpoch when any non-dry-run target succeeds.

* fix(fleet): toast partial prune success honestly

A reachable node with mixed per-target outcomes made okNodes zero and
showed a total-failure toast even when some targets mutated Docker.
Gate the failure toast on zero successful targets anywhere.
This commit is contained in:
Anso
2026-07-23 08:25:54 -04:00
committed by GitHub
parent bf7a8b5734
commit ed5ca9c4f6
3 changed files with 185 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/features/fleet-actions.mdx
+1 -1
View File
@@ -139,7 +139,7 @@ Scope is a segmented control with two options:
### Live estimate and behaviour
- Changing a target or the scope re-triggers a debounced call to `POST /api/fleet/prune/estimate`, which walks the same Docker enumeration the destructive path uses so the estimate matches what pruning would actually reclaim. **Prune fleet** stays disabled until the estimate resolves: you cannot confirm a destructive fleet-wide prune with no context on what it will reclaim.
- Changing a target or the scope re-triggers a debounced call to `POST /api/fleet/prune/estimate`, which walks the same Docker enumeration the destructive path uses so the estimate matches what pruning would actually reclaim. A completed real prune that succeeds on at least one target re-triggers the same estimate so the toolbar total and per-node list reflect post-prune Docker state. **Prune fleet** stays disabled until the estimate resolves: you cannot confirm a destructive fleet-wide prune with no context on what it will reclaim.
- Each remote node receives one `POST /api/system/prune/system` call per selected target, with a 120-second timeout. If a transport error fires for one target, the remaining targets on that node are short-circuited with the same error rather than retried, so a dead node doesn't absorb the full multi-target timeout budget.
- Local nodes serialize against a per-node lock (`bulk-prune:<nodeId>`). A second fleet prune launched against the same local node while the first is still in flight returns *A prune is already running on this node* for each target.
- Reclaimed bytes are reported by the Docker daemon and are approximate. Per-node rows in the results panel sum the per-target reclaim; the per-target children show how much each individual prune actually freed.