CI: cellpy_batch_processing notebook (nbmake) fails on master in pytest_posix.yml

[jepegit]

Summary

The pytest_posix.yml workflow has been failing on master for several consecutive runs. The failure is not in the test suite itself — the pytest step passes — but in the subsequent step:

Step 8: "pytest with nbmake (cellpy_batch_processing)"

This step executes the cellpy_batch_processing example notebook via nbmake, and it errors/hangs.

Evidence

• Job: Install-miniconda-and-run-pytest (3.13) in .github/workflows/pytest_posix.yml
• Steps 1–7 (Set up job … pytest) all pass; step 8 (nbmake on cellpy_batch_processing) fails.
• The last several pytest_posix.yml runs on master all failed at this same step (e.g. runs on 2026-06-14, 06-21, 06-22, 06-24).
• Surfaced while merging 153 pec reader #393 — the PEC-reader changes are unrelated; the core pytest step passed on every Python version (3.10–3.13). This is purely the notebook-execution check.

Impact

• master CI is red, so PRs show an UNSTABLE merge state and can't reach a fully-green CI.
• Masks real regressions: a genuinely broken PR could look "the same as master".

Likely causes to investigate

• A regression in the cellpy_batch_processing example notebook (stale API usage, missing/renamed data, env-specific path).
• An nbmake / dependency / kernel timeout issue specific to the notebook step.

Suggested next steps

• Run the cellpy_batch_processing notebook locally end-to-end and capture the failing cell.
• Fix the notebook (or the underlying API it exercises), or temporarily mark the nbmake step non-blocking / continue-on-error if it's environmental.
• Confirm pytest_posix.yml goes green on master again.

[jepegit]

Root cause pinpointed

Reproduced from the CI logs (latest master pytest_posix.yml run, job Install-miniconda-and-run-pytest (3.13)). It is not a crash — it is a cell timeout:

A cell timed out while it was being executed, after 3600 seconds.
The message was: Cell execution timed out.
Here is a preview of the cell contents:
-------------------
# Plot the charge capacity and the C.E. (and resistance) vs. cycle number (standard plot)
b.plot(rate=True)
-------------------
ERROR    traitlets:client.py:845 Timeout waiting for execute reply (3600s).

So the single hanging cell is:

b.plot(rate=True)

in examples/cellpy batch utility/cellpy_batch_processing.ipynb. It blocks for the full --nbmake-timeout=3600, failing the workflow.

Where it goes

• Batch.plot(...) (cellpy/utils/batch.py) with the default backend resolves to plotly → self.plotter.do(**kwargs).
• The kaleido image-export path in collectors.py is already guarded by a subprocess with IMAGE_TO_FILE_TIMEOUT = 30, so a 3600s hang is not the image export — it's the figure build/display path of plotter.do() with rate=True running headless on Linux CI.

Notes / hypotheses to check

• The hang is specific to rate=True (other cells in the notebook run fine before this one).
• Likely a blocking call during figure construction/display in a headless kernel (e.g. a renderer/browser call, or a multiprocessing/fork-related deadlock when spawning the export subprocess from inside the Jupyter kernel on Linux).

Suggested fixes (pick one)

• Reproduce b.plot(rate=True) headless with the notebook's example batch and get a stack trace (e.g. faulthandler.dump_traceback_later) to find the exact blocking call.
• If it's a renderer/display issue, force a non-interactive plotly renderer in CI (e.g. pio.renderers.default = "json"/"png") or pass a non-blocking option from plotter.do().
• As an interim CI unblock: lower --nbmake-timeout, mark this step continue-on-error, or skip/replace the b.plot(rate=True) cell so master CI is green again while the real hang is fixed.

[jepegit]

Interim CI unblock landed in #398 (squash-merged to master): the pytest with nbmake (cellpy_batch_processing) step is now continue-on-error with --nbmake-timeout lowered 3600 -> 600, so master goes green while the b.plot(rate=True) hang is still tracked here. Verified on the PR: the pytest_posix.yml job concluded success (nbmake step shows as a non-blocking step). This issue stays open for the real fix to the headless b.plot(rate=True) hang.