INITIALIZE · SERVE · DRAIN
Agent deployment: route only after readiness
Follow worker lifecycles and the invocations they own. Test readiness, shutdown deadlines and the point at which results commit.
Scroll the worker lanes horizontally. The worker inspector, sums and event trace below provide the same states as text.
Worker and invocation inspector
Committed-output fixture
Completed sums remain visible after a worker exits. This represents an external result store; browser reload does not persist it. Killed invocations have no committed output.
Recent lifecycle decisions
Your experiment
The broken router sends requests to starting workers. Inspect the rejection trace, then enable ready-only routing. With no ready worker, requests still fail; readiness protects correctness but does not invent spare capacity. Shorten startup or supply already available capacity to change that outcome.
Exactly what runs
Requests arrive from t = 1 s through t ≤ 40 s, at the selected interval. Each carries [request number, 1, 2]. The host assigns a free slot and models three equal-duration stages: prepare, model, tool. No AI is called. At completion, actual JavaScript addition computes and commits the sum. Each invocation owns one slot until it completes or its process is killed.
Ready-only routing picks the least-loaded ready worker, with worker ID as a deterministic tie-break. Without that guard it also considers starting and draining workers; those reject the request. There is no admission queue, retry, autoscaler or state transfer. A replacement is a single scheduled boot, not automatic recovery based on load. Startup failure affects only worker 1.
At the signal time, an enabled handler withdraws readiness and drains existing work; an ignored signal leaves the application ready until forced stop. A drained process exits immediately. At a shared timestamp, completions happen before readiness changes, termination and new admission; completion exactly at a shutdown deadline therefore wins in this model. Time is evaluated in 0.1 s steps.
Fixture gate, not a certification
PASS requires zero killed or still-running invocations and a final rejection percentage no greater than the selected allowance. It says nothing about authentication, model quality, real provider SLOs, latency percentiles or production correctness.
Offline, deliberately bounded lifecycle model. It does not execute an ADK Runner, Java process, container, operating-system signal or cloud deployment. Model/tool stages illustrate ownership and timing, not provider computation. The configurable grace period and router are teaching controls, not promises about any cloud runtime. Cloud Run’s documented termination contract and ADK’s invocation event loop must be consulted separately for real implementations. Cloud Run container contract · ADK runtime event loop.
Inspect a deployment readiness gap
The opening sets ten seconds of startup and disables ready-only routing. At one second the event trace says the request was routed before readiness; it has no output or worker ownership. Enable Route only to ready workers and repeat: the reason becomes no eligible worker while every host is still starting. Readiness changes correct admission behavior but cannot invent warm capacity. Shorten Startup duration to zero to remove that initial gap, then compare replacement startup around the signal. Seek to sixty seconds in the untouched opening: ten requests complete, ten are rejected and none are killed. This numerical scenario illustrates a router policy, not a prediction of Cloud Run behavior.
Trace ownership and actual output
Initial workers creates one to four workers, and Invocation slots per worker limits each worker to one to four simultaneous requests. Startup duration delays eligibility. Request interval schedules arrivals at one second and then regularly through forty seconds inclusive. Invocation duration holds each admitted slot through three illustrative stages: prepare, model and tool. At completion, JavaScript actually adds the request number, one and two. Seek to eight seconds after Common baseline settings and set startup to zero: request 1 has committed the sum four. Before completion its output is absent. These stage names do not represent real model or tool calls. There is no queue, retry, autoscaler, CPU contention or service-time slowdown as slots increase.
Withdraw readiness before draining
Route only to ready workers chooses the least-loaded ready worker, breaking ties by worker ID. Without it, starting or draining workers remain candidates and reject requests even when another worker could serve them. Fail initialization of worker 1 affects only that original worker. Signal worker 1 at chooses the termination time; Handle SIGTERM and stop admission changes that worker to draining. It accepts no new work and exits as soon as its current invocations finish. Grace period sets a forced-stop deadline. Without the handler, the worker stays eligible until that deadline and may admit requests that it cannot finish. Boot one replacement at signal time schedules one new worker with the same startup delay. It does not recover killed requests or replace every failed worker.
Account for every request
At every snapshot, arrivals equal admitted plus rejected. Admitted equals completed plus killed plus running. A killed request has no committed sum; completed sums remain in an external-store fixture after the owning worker exits. Reload does not persist that store. At equal timestamps, completion happens first, then readiness, signal and forced stop, and finally new admission. Therefore a completion exactly at the shutdown deadline wins here; real deployments need their own concurrency contract. The simulation uses tenth-second snapshots and stops at sixty seconds, after the last possible accepted request can finish. Fixture rejection allowance changes only the pass/fail threshold. Any killed or still-running invocation always fails the gate even at a one-hundred-percent rejection allowance.
Inspect time and worker state
Play runs sixty inspectable seconds at normal speed; Pause freezes time, and Play after completion replays from zero. Step 1 second advances to the next whole-second boundary and pauses. Restart preserves parameters and speed while returning to zero. Simulation time seeks directly and pauses. Speed provides quarter, half, normal and double pace; changing it settles elapsed time at the previous rate. A hidden tab pauses. Changing any model parameter rebuilds the plan and pauses at zero. Common baseline settings restores the shared model defaults, which differ from each page opening. Choose worker provides keyboard access to the same inspection as clicking its diagram lane. A replacement selected before its boot time has no state yet. Expand experiment changes the view; Exit full screen restores it.
Record evidence and understand the scope
Capture baseline saves the selected result and inputs; Replace baseline updates that comparison and Clear baseline removes it. Notes remain in this browser and Export notes downloads them. Scroll the diagram horizontally on phones, or focus its labeled region and use arrow keys. The worker inspector, committed sums and event trace provide text alternatives. The full-run preview intentionally exposes the eventual counts. This is a bounded teaching host, not an ADK Runner, Java process, operating-system signal, load balancer or cloud deployment. Grace and routing are configurable lesson assumptions, not provider guarantees. The fixture gate measures request accounting and the chosen rejection budget; it does not establish production availability, model quality, tenant isolation or real latency.