CI: GPU Build Cache runner shuts down mid-execution at `opt_savings_2` (DeadKernelError, on-demand)

[mmcky]

The weekly Build Cache [using jupyter-book] job on main (self-hosted RunsOn GPU runner, g4dn.2xlarge) has failed its last two scheduled runs — 2026-06-29 and 2026-07-06 — both while executing lectures/opt_savings_2.md.

Symptom

Mid-execution the runner is torn down, and the kernel dies as a consequence:

##[error]The runner has received a shutdown signal. This can happen when the runner service is stopped, or a manually started runner is canceled.
...
nbclient.exceptions.DeadKernelError: Kernel died
##[error]The operation was canceled.

What it is not

• Not spot reclamation. spot=false has been set on the GPU runners since ⚙️ Disable spot instances on GPU runners (use on-demand) #327 (merged 2026-06-26); both failures ran on on-demand instances.
• Not the Anaconda 2026.06 bump. The environment installs cleanly on anaconda=2026.06, the jax[cuda13] stack (jax/jaxlib 0.10.2, CUDA 13, driver 580) installs, and every notebook before opt_savings_2 executes and caches successfully — including the 184 s newtons_method. The build only dies once it reaches opt_savings_2.md.

Pattern

Same notebook, ~15 minutes into the run, both weeks. That points to a GPU resource issue (out-of-memory) or a runner max-duration / health reclaim specific to opt_savings_2.md, rather than a build-config or distribution problem.

History: green every week from 2026-05-04 through 2026-06-22, then red on 2026-06-29 and 2026-07-06.

Next steps

• Watch GPU memory while opt_savings_2 executes (suspect OOM on the shared GPU).
• Check for a RunsOn instance/job max-duration that the run is bumping into around the 15-minute mark.
• Confirm whether opt_savings_2.md (or its dependencies) changed recently in a way that grew its memory/runtime footprint.

Example runs

• 2026-07-06: https://github.com/QuantEcon/lecture-jax/actions/runs/28767921531
• 2026-06-29: https://github.com/QuantEcon/lecture-jax/actions/runs/28348894676