fix(self-hosting): add missing worker-executions service to compose generator#3055
fix(self-hosting): add missing worker-executions service to compose generator#3055scottgrobinson wants to merge 1 commit into
Conversation
…enerator Appwrite 1.9.0 moved execution persistence to a dedicated executions worker (entrypoint `worker-executions`) that consumes the `v1-executions` queue. The generated docker-compose only includes the `schedule-executions` scheduler, so nothing drains `v1-executions` and scheduled/async function executions are never written to the database (sync executions work because the API persists them inline). Add the `appwrite-worker-executions` service so self-hosted installs record executions correctly. Fixes appwrite#3054 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Greptile Summary
Confidence Score: 4/5The change is narrowly scoped, but the generated worker needs environment parity before it is safe for varied self-hosted configurations. The affected file and service block are small and the missing configuration is concrete; targeted execution confirmed the generated service omits the expected worker configuration variables. src/lib/components/compose-generator/composeData.ts
What T-Rex did
Reviews (1): Last reviewed commit: "fix(self-hosting): add missing worker-ex..." | Re-trigger Greptile |
| environment: | ||
| - _APP_ENV | ||
| - _APP_WORKER_PER_CORE | ||
| - _APP_OPENSSL_KEY_V1 | ||
| - _APP_DB_ADAPTER | ||
| - _APP_DB_HOST | ||
| - _APP_DB_PORT | ||
| - _APP_DB_SCHEMA | ||
| - _APP_DB_USER | ||
| - _APP_DB_PASS | ||
| - _APP_REDIS_HOST | ||
| - _APP_REDIS_PORT | ||
| - _APP_REDIS_USER | ||
| - _APP_REDIS_PASS | ||
| - _APP_LOGGING_CONFIG |
There was a problem hiding this comment.
Preserve worker environment parity
The new worker-executions service does not pass the full Appwrite 1.9.x environment contract for this entrypoint. The upstream service includes _APP_WORKERS_NUM=1, _APP_WORKER_MAX_COROUTINES=8, _APP_POOL_ADAPTER, and _APP_DATABASE_SHARED_TABLES, but this generated compose omits them. On installs that use shared database tables or a non-default pool adapter, the API and scheduler can enqueue execution work with one configuration while this worker starts with defaults or empty values, so execution upserts can fail or target the wrong table layout instead of fixing the stuck v1-executions queue. Please keep this worker's environment in parity with the upstream worker-executions service, including the pool adapter, shared tables setting, and worker concurrency settings.
Artifacts
Repro: generated config parity check script
- Contains supporting evidence from the run (text/javascript; charset=utf-8).
Repro: failing worker-executions environment parity output
- Keeps the command output available without making the summary code-heavy.
What does this PR do?
Adds the missing
appwrite-worker-executionsservice to the self-hosting Docker Compose generator.In Appwrite 1.9.0, execution persistence moved out of the functions worker into a dedicated executions worker (entrypoint
worker-executions,Appwrite\Platform\Workers\Executions) that consumes thev1-executionsqueue and upserts the execution document. The generated compose only includes theschedule-executionsscheduler — there is noworker-executionsservice — so nothing drainsv1-executions. As a result, on self-hosted installs:status: waitingforever.The queue silently accumulates (observed ~46k stranded jobs on an affected instance). Adding the worker drains the backlog immediately and executions persist as
completed.Test Plan
On a self-hosted 1.9.0 install with the added service:
docker compose up -d appwrite-worker-executionsv1-executionsqueue drains to 0 and scheduled/async executions appear in the Console with statuscompleted.Related PRs and Issues
Fixes #3056
The same omission exists in the main
appwrite/appwritecompose template (app/views/install/compose.phtml); a corresponding change there is likely needed too.