Skip to content

Docs: Compose template missing worker-executions service #3054

Description

@scottgrobinson

👟 Reproduction steps

Self-hosted Appwrite 1.9.0 via Docker Compose (upgraded from 1.8.x).

  1. Deploy a function with a cron schedule (e.g. * * * * *), or trigger any async execution (the Console's "Execute now", or POST /functions/{id}/executions with the async path).
  2. Wait for it to run, then open the function's Executions tab.

👍 Expected behavior

An execution record appears with status completed/failed and its logs/errors.

👎 Actual behavior

Nothing is recorded. The function code actually runs, but:

  • Scheduled executions produce no execution document at all.
  • Async http executions get created with status: waiting and stay stuck in waiting forever.
  • Synchronous executions work fine (they're persisted inline by the API), which masks the problem.
  • No errors surface anywhere (the queue job is even marked successful).

🔍 Root cause

In 1.9.0, execution persistence was moved out of the functions worker into a dedicated executions worker (Appwrite\Platform\Workers\Executions, getName() => 'executions'), which consumes the v1-executions queue (Event::EXECUTIONS_QUEUE_NAME).

The flow is now:

  1. Workers/Functions::execute() runs the function and dispatches ExecutionCompleted to the in-process Bus.
  2. The Bus\Listeners\Log listener publishes the execution to the v1-executions queue (it does not write to the DB directly).
  3. A worker-executions process is expected to consume v1-executions and persist the execution document.

But the Docker Compose template (app/views/install/compose.phtml) only defines appwrite-task-scheduler-executions (entrypoint schedule-executions) — there is no appwrite-worker-executions service (entrypoint worker-executions). So nothing consumes v1-executions; jobs pile up indefinitely (we observed ~46k stranded jobs) and executions are never written.

Two things make this hard to diagnose:

  • Utopia\Bus\Bus::dispatch() swallows listener exceptions (catch (\Throwable $e) { Span::error($e); } with no rethrow/log), so failures are silent.
  • The functions worker only logs Fetched 0 functions... (the event-trigger path), which is unrelated noise.

🩹 Fix

Add the missing worker-executions service to the compose template, e.g.:

  appwrite-worker-executions:
    image: appwrite/appwrite:1.9.0
    entrypoint: worker-executions
    <<: *x-logging
    container_name: appwrite-worker-executions
    restart: unless-stopped
    networks:
      - appwrite
    depends_on:
      redis:
        condition: service_healthy
      mariadb:
        condition: service_healthy
    environment:
      - _APP_ENV
      - _APP_WORKER_PER_CORE
      - _APP_OPENSSL_KEY_V1
      - _APP_REDIS_HOST
      - _APP_REDIS_PORT
      - _APP_REDIS_USER
      - _APP_REDIS_PASS
      - _APP_DB_ADAPTER
      - _APP_DB_HOST
      - _APP_DB_PORT
      - _APP_DB_SCHEMA
      - _APP_DB_USER
      - _APP_DB_PASS
      - _APP_USAGE_STATS
      - _APP_LOGGING_CONFIG

After adding it and running docker compose up -d appwrite-worker-executions, the v1-executions backlog drains immediately and scheduled/async executions are persisted (status completed) as expected.

🎲 Appwrite version

Version 1.9.0 (self-hosted, Docker)

💻 Operating system

Linux

🧱 Your Environment

Docker Compose deployment. Confirmed the same omission in the shipped 1.9.0 compose template (app/views/install/compose.phtml): it contains schedule-executions but no worker-executions.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions