weiqingy opened a new issue, #889: URL: https://github.com/apache/flink-agents/issues/889
### Search before asking - [x] I searched in the [issues](https://github.com/apache/flink-agents/issues) and found nothing similar. ### Description The `it-java` and `it-python` CI jobs fail intermittently for reasons unrelated to the code under test. A [recent run](https://github.com/apache/flink-agents/actions/runs/29032939015) shows both failure modes at once, with every unit-test job green. **1. The Ollama install step fails on a transient network blip.** `tools/start_ollama_server.sh` pipes `https://ollama.com/install.sh` into `sh`. That upstream script probes for `ollama-linux-${ARCH}.tar.zst` with a `curl --fail --silent --head`, and on any failure of that single probe it falls through to a `.tgz` asset. Current releases publish only `.tar.zst` — `.tgz` returns `404`. So one flaky HEAD request turns into a hard failure: ``` >>> Downloading ollama-linux-amd64.tgz curl: (22) The requested URL returned error: 404 gzip: stdin: unexpected end of file tar: Child returned status 1 ##[error]Process completed with exit code 2. ``` Two `it-java` jobs failed this way, before compiling or running a single test. Retrying the install would recover, since the underlying asset does exist. **2. The wrapper masks a failed download.** In `tools/start_ollama_server.sh`, `ret=$?` is read after `curl -fsSL ... | sh`, so it captures the exit status of `sh`, not `curl`. Without `pipefail`, a failed `curl` leaves `sh` reading empty stdin and exiting `0` — CI then proceeds with no Ollama installed and fails later somewhere less obvious. **3. Integration jobs have no runtime bound.** No job in `ci.yml` sets `timeout-minutes`. In the run above, `it-python [python-3.12] [flink-2.2]` hung and was killed at GitHub's 6-hour ceiling (`6h0m16s`), consuming shared runner capacity for a result that was knowable in minutes. A `timeout-minutes` on the integration jobs would surface the same failure far sooner. **Open question — the hang itself.** In that job Ollama installed correctly, then `llama-server` crashed while serving `qwen3:1.7b`: ``` ollama._types.ResponseError: llama-server process has terminated: signal: segmentation fault (core dumped) ``` Every failing test there is Ollama-backed; the `py4j` errors are downstream of the dead model server. I don't yet have evidence for the root cause (upstream regression, runner memory, or model artifact). One option is pinning `OLLAMA_VERSION` — `install.sh` supports it, and the workflow already pins `uv` to `0.11.0` in the adjacent step — which would at least make the toolchain deterministic. I'd welcome opinions on whether that's worth doing, and on how the project wants to handle bumping such a pin. If this direction sounds right, I'd propose splitting the work into two independent PRs: the retry plus `pipefail` fix in `tools/start_ollama_server.sh`, and the `timeout-minutes` addition in `ci.yml`. ### Are you willing to submit a PR? - [x] I'm willing to submit a PR! -- 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]
