weiqingy commented on issue #893: URL: https://github.com/apache/flink-agents/issues/893#issuecomment-4938712266
Correction to my previous comment: the release timeline rules out the Ollama-version-bump hypothesis, so a version pin is unlikely to help. Ollama's release dates around the onset (from the GitHub releases API): - v0.31.1 — 2026-06-30 - v0.31.2 — 2026-07-06 - (no release after 07-06) `tools/start_ollama_server.sh` installs the latest Ollama, which has been v0.31.2 since 07-06. So the green runs on 07-07 and 07-08 already installed v0.31.2, and the red runs on 07-10 installed that same v0.31.2 — the version was constant across the green→red boundary. Pinning `OLLAMA_VERSION` would only pin back to a version that was already both green and red, so it cannot explain or fix the onset. The "external, dated onset, not a PR" conclusion still holds — eight straight green runs through 07-08 rule out chance — but the external change is not the Ollama version. The leading explanation is the GitHub-hosted runner image rolling forward within `ubuntu-latest` (kernel `6.17.0-1018-azure` on a current runner), which is not pinnable via `OLLAMA_VERSION`. Two more data points fit an environmental cause: v0.31.2 runs thousands of concurrent, grammar-constrained, model-churning inferences without a crash in an isolated Ollama-only job, yet within a single CI run the same v0.31.2 both passes and crashes across different matrix legs. Since the cause is environmental and per-runner, the mitigation that is robust regardless of the exact trigger is to re-run only the failed integration-test jobs on a fresh runner, which resets the whole job environment. Opened as #895. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
