👟 Reproduction steps

1. Keep a function busy with synchronous executions (we used 40 parallel loops of POST /v1/functions/{id}/executions).
2. Create a new deployment with activate=true and wait until it's ready.

👍 Expected behavior

Executions switch from the old to the new deployment without errors.

👎 Actual Behavior

Right before the deployment reports ready, a handful of executions fail:

{"message":"Build with the requested ID is building and not ready for execution.","code":400,"type":"build_not_ready","version":"2.3.0"}

In our runs it was 11–13 failed executions per deployment, all within about 20 ms, on both API nodes (one probe: 13 of 8,530 executions, between +7.96 s and +7.98 s after the upload; the deployment turned ready at +8.19 s as seen by polling).

This is the other side of #13741. That PR made the builds worker call activate() first (repoint the rules, then set the function's deploymentId) and only then set the deployment's status to ready (Jobs.php on 2.3.0, L609–L622; unchanged in 2.4.0, now in finalize(): L745–L755), so a client that sees ready can always execute. For the first deployment that's right. For a new deployment of a function that is already live, it opens the opposite window: the function already points to a deployment that is still building, and Executions/Create.php L203–L205 rejects it. Before the switch, the previous deployment would have served those requests. The window grows with the time activate() takes to walk the matching rules.

The Sites router checks the same status (general.php L352) and serves a "build not ready" error page instead, so site requests during a redeploy are probably affected the same way. We haven't measured that.

🎲 Appwrite version

Measured on 2.3.0; the same order of writes is in 2.4.0

💻 Operating system

Linux (Debian 12), Docker

🧱 Your Environment

Self-hosted, two API nodes, executor and builds on one of them, Postgres on a separate node. Function runtime dart-3.13.

💡 Suggested fix

Swapping the two writes back would bring back the 404 that #13741 fixed. Two options that close both windows:

• Write the function's deploymentId (end of activate()) and the deployment's status => ready in one transaction on dbForProject. Both documents live in the project database; the rules on the platform database are already repointed before that.
• Or let the execution endpoint and the router accept the function's active deployment once the build has finished (e.g. buildEndedAt set and the build output present), instead of requiring status === 'ready' at that exact moment.

👀 Have you spent some time to check if this issue has been raised before?

• I checked and didn't find a similar issue

🏢 Have you read the Code of Conduct?

• I have read the Code of Conduct