👟 Reproduction steps
Self-hosted Appwrite 1.9.0 via Docker Compose (upgraded from 1.8.x).
- 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).
- 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:
Workers/Functions::execute() runs the function and dispatches ExecutionCompleted to the in-process Bus.
- The
Bus\Listeners\Log listener publishes the execution to the v1-executions queue (it does not write to the DB directly).
- 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.
👟 Reproduction steps
Self-hosted Appwrite 1.9.0 via Docker Compose (upgraded from 1.8.x).
* * * * *), or trigger any async execution (the Console's "Execute now", orPOST /functions/{id}/executionswith the async path).👍 Expected behavior
An execution record appears with status
completed/failedand its logs/errors.👎 Actual behavior
Nothing is recorded. The function code actually runs, but:
httpexecutions get created withstatus: waitingand stay stuck inwaitingforever.🔍 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 thev1-executionsqueue (Event::EXECUTIONS_QUEUE_NAME).The flow is now:
Workers/Functions::execute()runs the function and dispatchesExecutionCompletedto the in-processBus.Bus\Listeners\Loglistener publishes the execution to thev1-executionsqueue (it does not write to the DB directly).worker-executionsprocess is expected to consumev1-executionsand persist the execution document.But the Docker Compose template (
app/views/install/compose.phtml) only definesappwrite-task-scheduler-executions(entrypointschedule-executions) — there is noappwrite-worker-executionsservice (entrypointworker-executions). So nothing consumesv1-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.Fetched 0 functions...(the event-trigger path), which is unrelated noise.🩹 Fix
Add the missing
worker-executionsservice to the compose template, e.g.:After adding it and running
docker compose up -d appwrite-worker-executions, thev1-executionsbacklog drains immediately and scheduled/async executions are persisted (statuscompleted) 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 containsschedule-executionsbut noworker-executions.