[Endle]

ollama-live (ubuntu-latest) failed 3 of the last 12 live-llm runs with a byte-identical signature:

chat 500 Internal Server Error: {"error":{"message":
"llama-server process has terminated: signal: segmentation fault (core dumped)"}}

Every time: embed_returns_a_vector passes in ~0.4s, then both chat tests die on the same crashed runner. Always ubuntu, never macOS, on identical test code.

(Two other red runs — 29944352897, 29944374576 — failed all four jobs on cannot update the lock file ... because --locked was passed. That was the stale lockfile, fixed by #178, not flake.)

Why not just relax the assertions

That was the first instinct, but there is nothing left to loosen. The strongest assertions in llm_backend_live.rs are !answer.trim().is_empty() and !assembled.trim().is_empty(); no test inspects model output at all — "Reply with exactly the word: pong" isn't even checked against "pong". The failure is an HTTP 500 with an empty body because Ollama's subprocess died, so the only thing that would turn it green is continue-on-error, which doesn't relax a threshold — it removes the job's ability to report anything. This is the sole coverage of the OpenAI-compat wire format and the LlmFlavour::Ollama shim, so that trade seemed bad.

What this changes

• Run the three tests serially. They otherwise execute concurrently, landing two simultaneous chat requests on one qwen2.5:0.5b runner — the shape in which Ollama segfaults.
• Pin OLLAMA_MAX_LOADED_MODELS / OLLAMA_NUM_PARALLEL on ollama serve, not on the cargo step. Those vars are read by the server process; on the test step they would have done nothing.
• Stop the systemd unit the Linux installer starts. It already owned :11434, so the old ollama serve & silently lost the bind and the job passed against an unconfigured instance — visible as bind: address already in use in run 29944352897. Without this, the env above is ignored on Linux.
• Dump the server log on failure. A segfault reaches the test as an empty 500, which is why this recurred three times undiagnosed.

No test file is touched; no assertion is weakened.

Verification

Ran locally against Ollama with the CI models (qwen2.5:0.5b, all-minilm):

running 3 tests
test chat_returns_text ... ok
test chat_stream_yields_deltas ... ok
test embed_returns_a_vector ... ok
test result: ok. 3 passed; 0 failed; finished in 1.44s

Caveats

The concurrency diagnosis is inference from the timing, the ubuntu/macOS split, and which test survives — not a captured stack trace. The log dump is what will confirm or refute it on the next occurrence. Given a 25% base rate, a few green runs won't be proof either; if it recurs, the log will finally say why, and the fallback is one bounded retry of the step rather than continue-on-error.

--test-threads=1 also makes the job strictly serial, which costs a little wall time (~1.4s of test execution here, dwarfed by model pulls).

🤖 Generated with Claude Code