josh/electric-cherry
1
0
Fork 0
Code Issues 18 Pull Requests Actions Packages Projects Releases Wiki Activity

Add configurable server destruction concurrency

Browse Source
This commit is contained in:
josh
2026-10-01 11:29:55 -04:00
parent 30030599d6
commit aa0223c35d
7 changed files with 359 additions and 84 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+10 -3
View File
@@ -118,7 +118,8 @@ for verification, retry, scheduling, and compatibility details.
## Fleet settings
**Settings → Fleet settings** controls campaign history retention (default 7 days),
concurrent restarts (default 1), and concurrent server startups (default 1).
concurrent restarts (default 1), concurrent server startups (default 1), and
concurrent server destructions (default 1).
Values are positive whole numbers; retention supports up to 36500 days. Settings
are saved in SQLite for all users and apply at the next queue or cleanup check
without restarting the app. Lowering a limit leaves active operations running
@@ -134,9 +135,11 @@ On the first startup after upgrading, existing `DEPLOY_KEEP_DAYS`,
values initialize the saved settings. Keep custom values for that first startup;
afterward, the database values take precedence and those variables can be removed.
The supplied Compose and Komodo examples use the built-in defaults.
Existing saved settings retain their values when upgraded; the destruction
limit starts at 1 and can be changed in Settings.
`GET /api/settings` reads the three values (`deployKeepDays`, `restartConcurrency`,
`createConcurrency`); `PUT /api/settings` saves all three together as JSON.
`GET /api/settings` reads the four values (`deployKeepDays`, `restartConcurrency`,
`createConcurrency`, `destroyConcurrency`); `PUT /api/settings` saves all four together as JSON.
Invalid or incomplete requests return HTTP 400 without changing saved settings.
## How restarts stay safe
@@ -447,6 +450,10 @@ when creation began. The page retains its last snapshot if a refresh fails.
Destroy uses an in-app confirmation modal and immediately returns a queued deployment (`DELETE /api/servers/:name` returns HTTP 202 with `deploymentId`). The worker waits for a fresh zero-player RCON or telemetry report, or a verified stopped container, before teardown. Occupied reports from either source block teardown; servers without current verification remain queued and are checked each worker tick. Waiting requests survive application restarts, while interrupted teardown is marked for inspection. Completed destruction stays on the provisioning detail page.
**Settings → Concurrent server destructions** limits simultaneous individual and
fleet removals (default 1). Each destruction holds its slot through teardown and
local cleanup. Lowering the limit lets active removals finish before more begin.
Use **Provisioning → Manage server**, or a server’s **Server actions**, to start,
restart, stop, or rebuild an existing instance. **Rebuild destroys and creates in