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

  1. Wait — this error is retry-by-design; BullMQ will re-attempt with backoff while Ollama warms up.
  2. Verify the service: curl http://localhost:11434/api/tags returns a JSON array.
  3. If it keeps failing, check Ollama container logs (docker logs nomad_ollama) for crashes or port conflicts.
  4. 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

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.