fleet/fleetd
3
0
Fork 0
Code Issues 78 Pull Requests Actions Packages Projects Releases 1 Wiki Activity

fleetd #664: explain delayed jar failure
CI / shell-tests (pull_request) Failing after 8s
Details
CI / contract (pull_request) Successful in 55s
Details
CI / build (pull_request) Failing after 1m43s
Details

Browse Source
This commit is contained in:
Dai Ha
2026-10-03 19:36:08 +02:00
parent a5d6ce1a37
commit 41cc785534
2 changed files with 7 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.claude/skills/redeploy-fleetd/SKILL.md
+3 -1
View File
@@ -29,7 +29,8 @@ and dies with `no jar at … — run without --no-build` if it is not, but it ca
old. Any build that writes `fleetd/target/fleetd.jar` while the daemon runs, including `mvn install`
with or without `clean`, breaks that daemon's shutdown drain. The drain loads its classes lazily at
shutdown from the jar file the JVM opened at boot. Deleting is not the only hazard; replacing the jar
is enough. Verify a merge by building in a throwaway git worktree. Let only
is enough. Nothing warns at the time. The damage appears at the next restart, where it looks like the
restart's fault. Verify a merge by building in a throwaway git worktree. Let only
`scripts/redeploy-fleetd.sh` touch the main clone's jar. Its stage-then-swap protects its own build,
but it cannot undo a replacement that already happened. Run `--check` first: it prints the jar's hash
and its modification time, so you can see for yourself whether the jar is missing or older than the
@@ -74,3 +75,4 @@ start every time. The rule lives in the operator's Claude Code settings:
Granted by the operator on 2026-08-15. If a call is still refused, do **not** route around it by
running the stop and start as separate commands — that is exactly the approval the script replaced.
Say what you were going to run and why, and let the operator decide.
CLAUDE.md
+4 -3
View File
@@ -325,9 +325,10 @@ must obey belongs in the charter, not here.
file because this file loads into every session's context.
- **Never build into the main clone while `fleetd` runs.** Any build that writes
`fleetd/target/fleetd.jar`, with or without `clean`, breaks the shutdown drain because its classes
load lazily from the jar file the JVM opened at boot. Verify merges in a throwaway git worktree.
Let only `scripts/redeploy-fleetd.sh` touch the main clone's jar. Its stage-then-swap cannot undo
a replacement that already happened.
load lazily from the jar file the JVM opened at boot. Nothing warns at the time. The damage appears
at the next restart, where it looks like the restart's fault. Verify merges in a throwaway git
worktree. Let only `scripts/redeploy-fleetd.sh` touch the main clone's jar. Its stage-then-swap
cannot undo a replacement that already happened.
### Redeploying the daemon — the lead may do this (primary only)