Crosstalk-Solutions/project-nomad · warning · Error
Ollama service not ready yet
Error message
Ollama service not ready yet
What it means
Thrown by DownloadModelJob.handle() when ollamaService.getModels() returns a falsy value. getModels() presumably returns null/undefined when the Ollama HTTP API isn't responding yet (connection refused or timeout), so the job treats it as 'service not ready' and relies on BullMQ retrying with backoff — the log explicitly says 'Will retry...'.
Source
Thrown at admin/app/jobs/download_model_job.ts:56
const queue = queueService.getQueue(this.queue)
const client = await queue.client
await client.set(this.cancelKey(jobId), '1', { EX: 300 }) // 5 min TTL
}
async handle(job: Job) {
const { modelName } = job.data as DownloadModelJobParams
logger.info(`[DownloadModelJob] Attempting to download model: ${modelName}`)
const ollamaService = new OllamaService()
// Even if no models are installed, this should return an empty array if ready
const existingModels = await ollamaService.getModels()
if (!existingModels) {
logger.warn(
`[DownloadModelJob] Ollama service not ready yet for model ${modelName}. Will retry...`
)
throw new Error('Ollama service not ready yet')
}
logger.info(
`[DownloadModelJob] Ollama service is ready. Initiating download for ${modelName}`
)
// Register abort controller for this job — used both by in-process cancels (same process
// as the API server) and as the target of the Redis poll loop below.
const abortController = new AbortController()
DownloadModelJob.abortControllers.set(job.id!, abortController)
// Get Redis client for checking cancel signals from the API process
const queueService = QueueService.getInstance()
const cancelRedis = await queueService.getQueue(DownloadModelJob.queue).client
// Track whether cancellation was explicitly requested by the user. Only user-initiated
// cancels become UnrecoverableError — other failures (e.g., transient network errors)
// should still benefit from BullMQ's retry logic.View on GitHub (pinned to 0bd1c6f4f9)
Solutions
- Wait — this error is retry-by-design; BullMQ will re-attempt with backoff while Ollama warms up.
- Verify the service: curl http://localhost:11434/api/tags returns a JSON array.
- If it keeps failing, check Ollama container logs (docker logs nomad_ollama) for crashes or port conflicts.
- Confirm the Ollama URL configured in dockerService/ollamaService matches the deployed port.
Example fix
# shell docker ps --filter name=ollama curl -s http://localhost:11434/api/tags | head -c 200
Defensive patterns
Strategy: retry
Validate before calling
const models = await ollamaService.getModels().catch(() => null)
if (!models) { /* delay enqueue until Ollama is up */ } Try / catch
catch (err) {
if (err instanceof Error && err.message === 'Ollama service not ready yet') {
return // BullMQ backoff will retry; do not alert
}
throw err
} Prevention
- Add a readiness probe on Ollama before enqueuing model jobs.
- Use a sufficient backoff strategy on the worker for startup races.
- Distinguish this retryable 'not ready' from the unrecoverable 'not installed' error.
When it happens
Trigger: Ollama container/service is starting up and its API port isn't listening; getModels() catches the connection error and returns null; the model download job was enqueued immediately after install/start.
Common situations: Fresh install of the AI Assistant stack where Ollama takes longer to boot than the job's first attempt, Docker container restarting or OOM-killed, Ollama listening on a non-default port/URL, heavy disk/CPU load slowing startup.
Related errors
AI-assisted analysis of Crosstalk-Solutions/project-nomad@0bd1c6f4f9 (2026-08-27).
Data as JSON: /api/errors/8574ace49702d4db.
Report an issue: GitHub.