vh/esh-pfi-infrastructure
1
0
Fork 0
Code Issues 7 Pull Requests Actions Packages Projects Releases Wiki Activity

docs(waterland-studio): note why an adopted job shows as failed

Browse Source 
waterland-dev confirmed the mechanism: adoption marks a job failed on a
sidecar saying running/queued, or on a directory with no plate.png. The
pre-header-fix renders died 1.7s in with a source and no plate, so they
land in the second branch. Recorded so nobody investigates adopted
history as a live fault.
This commit is contained in:
vh
2026-08-19 01:40:52 -07:00
parent e6907819b0
commit 059f963118
1 changed files with 7 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
stacks/waterland-studio/README.md
+7
View File
@@ -161,3 +161,10 @@ Verified here after the update: `/api/jobs` went **1 → 16** against 16
directories on disk, with nothing reclaimed — correct, since 16 is under
`RETAIN=40`; adoption only made them visible. The bound now holds across
restarts, so no hand-pruning is needed.
**Don't chase the one `failed` job in that list.** Adoption marks a job
`failed` on exactly two conditions: a sidecar saying `running`/`queued`, or a
directory with no `plate.png`. The renders that died 1.7 s in on the missing
CUDA headers (before that fix) wrote a source and never a plate, so they land
in the second branch. It is adopted history being labelled honestly, not a
current fault.