A job whose runner dies leaves nothing on either side: GitHub archives no step log, and the fleet exports no bundle unless the repository and pool are in the canary list. Two sessions have now guessed at the cause of the same failure because there was nothing to read.
The scope, live
/etc/gha-fleet/diagnostic-exporter.yaml on the services host:
deployment_stage: canary
repositories:
- NDDev-it-com/almaty-libraries
- NDDev-it-com/github-actions
- ai-engineers-guild/ai_stp
pools:
- nddev-linux-container-canary
- nddev-linux-docker-container-canary
Everything else — every ordinary repository, and standard, fast, integration, untrusted, release and the priority classes — runs with no export.
The case that shows the cost
NDDev-it-com/client-kms-harvester-c runs CodeQL c-cpp on the fleet. Three attempts died inside the Custom build step: the step reported no conclusion and GitHub archived no log. The recorded diagnosis was a fleet memory problem. GARM's journal for worker nddev-htrjievffypf refutes it:
01:50:52 provider-create-started
01:51:02 provider-create-completed duration_ms 9713
01:52:06 job started native / CodeQL (c-cpp)
02:02:23 job completed (GitHub-reported)
02:02:23 deleting instance in provider
02:02:28 updates channel closed
Clean create, clean delete, no OOM, no orphan, no terminal circuit, no cancellation. So the fleet did not kill the job — but proving that took reading GARM's journal by hand, and it still does not say what happened inside the worker, because no bundle exists for it.
What would close this
Export for every repository and every pool the fleet runs, not a canary subset — the retention, size bounds and redaction that already work stay as they are. The canary stage proved the mechanism; the mechanism is now the only place a dead runner leaves a trace.
The master plan's Phase 2 gate is that a success, a product failure and an infrastructure failure can each be reconstructed end to end. Today the third one cannot be, for most of the estate.
https://claude.ai/code/session_01BjpW1NtF1oik18aEMMGtMP
A job whose runner dies leaves nothing on either side: GitHub archives no step log, and the fleet exports no bundle unless the repository and pool are in the canary list. Two sessions have now guessed at the cause of the same failure because there was nothing to read.
The scope, live
/etc/gha-fleet/diagnostic-exporter.yamlon the services host:Everything else — every ordinary repository, and
standard,fast,integration,untrusted,releaseand the priority classes — runs with no export.The case that shows the cost
NDDev-it-com/client-kms-harvester-cruns CodeQLc-cppon the fleet. Three attempts died inside theCustom buildstep: the step reported no conclusion and GitHub archived no log. The recorded diagnosis was a fleet memory problem. GARM's journal for workernddev-htrjievffypfrefutes it:Clean create, clean delete, no OOM, no orphan, no terminal circuit, no cancellation. So the fleet did not kill the job — but proving that took reading GARM's journal by hand, and it still does not say what happened inside the worker, because no bundle exists for it.
What would close this
Export for every repository and every pool the fleet runs, not a canary subset — the retention, size bounds and redaction that already work stay as they are. The canary stage proved the mechanism; the mechanism is now the only place a dead runner leaves a trace.
The master plan's Phase 2 gate is that a success, a product failure and an infrastructure failure can each be reconstructed end to end. Today the third one cannot be, for most of the estate.
https://claude.ai/code/session_01BjpW1NtF1oik18aEMMGtMP