Async createExecution returns 202 with an id that getExecution can 404 until ClickHouse persistence

👟 Reproduction

1. Self-hosted Appwrite 2.5.x (ClickHouse executions store).
2. POST /v1/functions/{functionId}/executions with async: true → 202 and an execution.$id.
3. Immediately (or within ~1–2s) GET /v1/functions/{functionId}/executions/{executionId} with the same project/auth.
4. Intermittently get 404 execution_not_found.
5. Retrying the same GET shortly after often succeeds; the function itself may still run normally.

Observed behavior

Create builds the execution document in memory, dispatches ExecutionScheduled, enqueues the function, and returns 202 without waiting for the executions worker to executionStore.upsert() into ClickHouse.

getExecution reads only via executionStore (ClickHouse), not MariaDB. So the id in the create response is not always GET-visible yet.

API logs show listener.log.event = ExecutionScheduled / success = true on the POST, then 404 on the GET for the same id.

Expected behavior

Either:

• Persist (or acknowledge) a GET-visible “waiting” execution before returning 202, so getExecution is read-after-write safe for the returned id; or
• Document that early 404 on poll is expected and specify a retry window / Retry-After.

Returning an id that the poll endpoint cannot find violates the create → poll flow described in the docs.

Appwrite version

2.5.x (self-hosted). Same architecture since ~2.2 “executions live in ClickHouse.”

-# debugged with AI for the reason for the create write lag

Also the reason is AI generation that takes more than 30s sometimes, so i run it async and poll the execution to know when it's finished (i get the output from a document with the same execution id)