What

Jobs::finalize() wrote the terminal status onto the deployment before it pointed the resource at that deployment. Between those two writes the API reported a build as ready while the function still had an empty deploymentId, so a client that polled for ready and immediately executed got 404 DEPLOYMENT_NOT_FOUND from POST /v1/functions/:functionId/executions.

The order was: guarded status => ready write → updateLatestDeployment() → activate(), and activate() walks every matching platform rule in dbForPlatform before it writes deploymentId. That rule scan is what makes the window wide enough to lose in practice.

Why now

It is the cause of the flake on FunctionsCustomServerTest::testDeploymentBuildOutputIsServedFromTheBuildsDevice in the s3 group. On this run 19 assertions passed and then the execution came back 404, with the server logging Deployment not found. Create a deployment before trying to execute a function from Executions/Create.php. The whole test ran in 4.0 seconds, so it lost the race by milliseconds. It is not a test-only problem: any SDK user doing create-then-poll-then-execute can hit the same window.

How

Split the terminal write in two so the status flip is the last thing finalize() does. Build metadata and the latestDeployment* pointer land first, then activation, then the status. The invariant becomes: a deployment never reports ready until everything reachable from a ready deployment is already durable.

Details worth reviewing:

• Both writes keep the Query::notEqual('status', 'canceled') guard, so a concurrent cancel still wins. The second guard matters because the cancel endpoint falls back to an unlocked write under lock contention.
• latestDeploymentStatus is now refreshed after the flip instead of carrying it. Leading with it would let a client that force-activates on seeing ready race BUILD_NOT_READY from the activation endpoint. updateLatestDeployment() returns the id it pointed at so the follow-up write is sparse and needs no second query.
• updateLatestDeployment() still runs before activate(), preserving the existing fix for clients observing a stale latestDeploymentId.
• The legacy Builds.php worker never writes ready, so no change is needed there.

Test

The e2e probe now asserts the invariant in the same iteration that first observes ready, and throws Critical so assertEventually aborts instead of retrying the failure away. That makes it deterministic rather than a second flaky check: on the old ordering it fails whenever the window is open, and on the new ordering it cannot fail.

Verified locally: php -l, Pint, and PHPStan level 4 all clean on the changed files. E2E needs CI.