Skip to content

fix(self-hosting): add missing worker-executions service to compose generator#3055

Open
scottgrobinson wants to merge 1 commit into
appwrite:mainfrom
scottgrobinson:fix/compose-add-worker-executions
Open

fix(self-hosting): add missing worker-executions service to compose generator#3055
scottgrobinson wants to merge 1 commit into
appwrite:mainfrom
scottgrobinson:fix/compose-add-worker-executions

Conversation

@scottgrobinson

@scottgrobinson scottgrobinson commented Jun 17, 2026

Copy link
Copy Markdown

What does this PR do?

Adds the missing appwrite-worker-executions service 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 the v1-executions queue and upserts the execution document. The generated compose only includes the schedule-executions scheduler — there is no worker-executions service — so nothing drains v1-executions. As a result, on self-hosted installs:

  • Scheduled executions are never recorded.
  • Async executions get stuck in status: waiting forever.
  • Synchronous executions work (the API persists them inline), which masks the issue.

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-executions
  • The v1-executions queue drains to 0 and scheduled/async executions appear in the Console with status completed.

Related PRs and Issues

Fixes #3056

The same omission exists in the main appwrite/appwrite compose template (app/views/install/compose.phtml); a corresponding change there is likely needed too.

…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-apps

greptile-apps Bot commented Jun 17, 2026

Copy link
Copy Markdown
Contributor

Greptile Summary

  • Adds the missing appwrite-worker-executions service to the self-hosting Docker Compose generator.
  • Wires the new worker to Redis, the configured database service, the Appwrite network, and core worker/logging environment variables.
  • Uses the worker-executions entrypoint so generated self-hosted compose files can drain the v1-executions queue.

Confidence Score: 4/5

The 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

T-Rex T-Rex Logs

What T-Rex did

  • Ran a targeted Node repro script against the compose generator template to verify appwrite-worker-executions parity; the generated environment list omitted _APP_WORKERS_NUM=1, _APP_WORKER_MAX_COROUTINES=8, _APP_POOL_ADAPTER, and _APP_DATABASE_SHARED_TABLES, and the parity check against the upstream Appwrite 1.9.x contract failed on four variable assertions.
  • Compared the base and head generated compose configurations; the baseline reported has appwrite-worker-executions service=false and has entrypoint worker-executions=false, whereas the head reports them as true and shows redis and mongodb in depends_on.

View all artifacts

T-Rex Ran code and verified through T-Rex

Reviews (1): Last reviewed commit: "fix(self-hosting): add missing worker-ex..." | Re-trigger Greptile

Comment on lines +680 to +694
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

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 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.

View artifacts

T-Rex Ran code and verified through T-Rex

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Docs: self-hosting compose generator missing worker-executions service (1.9.0)

1 participant