Deployment and readiness
The application started. Is it ready for requests?
A saved declaration, a live process, a readiness signal and a published route complete at different times. Follow Yaoploy into Yaogress to establish when a replica can serve a request.
Name the result meant by deployment completion
An App declaration records the intended image, replica count and optional public HTTP service. After it commits, Yaoploy assigns work within current managed membership. Agents still need to obtain the image, prepare its environment and start the application. These actions are not one transaction with declaration storage.
The design separates four results: a saved declaration, a live child, an eligible ready instance and a gateway configuration matching current endpoints. Keeping them separate explains a running process that is not yet serving traffic. The following describes the specified decisions, rather than a report of completed deployment tests.
Accept readiness from the actual current invocation
For a Listener application, the Agent binds a real socket and passes that same descriptor to the child. Readiness uses a separate pipe: the current live child must write the required byte and close the pipe. A port number, a PID or the byte without EOF does not complete that notification.
Local Ready must also match the server’s current session, adopted plan, image and listener binding before entering the public endpoint set. A late signal from an old child cannot ready its replacement. Workers have a different contract: a live foreground child is ready, while successful business processing remains an application result.
| Observation | Establishes | Does not yet establish |
|---|---|---|
| App declaration committed | Current intent is saved | Launch or predecessor termination |
| RUNNING | A Listener child is live and awaiting notification | Application readiness |
| Eligible READY | Current invocation and plan agree | Ingress reachability or a successful request |
A disconnected node may still run its old replica
Consider a two-replica application. Node A loses its control session and the server assigns replacement work to node C. Current membership can return to two replicas while A’s process remains alive. The requested count is a convergence target in the managed population, not a global cap on every process.
Exclusive database writes, order deduplication and authority over external resources therefore cannot rely on a replica count of one. Applications establish those conditions at their own business boundaries. Agents still retain responsibility for live children, sockets and mounts; removal from membership does not settle local resources.
Current capacity may be replenished
Once the old node leaves current membership, scheduling can converge using available capacity.
Do not infer that the old process ended
Session loss and remote process termination are different observations.
Publish routes from the complete current projection
Each public App projects to one complete Yaogress Service containing every selected suffix and every eligible ready backend. With no ready backend, no desired Service remains. A conflicting route owned elsewhere withholds the whole projection rather than publishing an unblocked subset. Execution and gateway states are recorded separately.
Synced establishes equality between the observed Service and the intended projection. A real request still needs Host routing: Exact first, Any only on a miss, then one fixed backend for the exchange. A connection or transfer failure does not authorize another business request, so actual application delivery requires its own response observation.
Continue the investigation at the responsible layer
Start from the strongest observation already available. Repeating a declaration cannot replace readiness, and refreshing gateway status cannot establish application cleanup. The following sequence retains the current subject and observation without turning every layer into a new control protocol.
Check the declaration and scope
Read the App, image and requested count, keeping current-membership scope explicit.
Inspect the actual invocation
Inspect plan adoption, running state, readiness and any stopping owner.
Inspect the gateway projection
Distinguish Pending, Conflict, Failed and Synced, then observe a real application request.
Verify with scenarios that expose wrong conclusions
Verification independently observes the process, control session, Service record and HTTP exchange. A green page alone cannot establish those bindings. These specified scenarios separately expose stale readiness, widened membership claims and partial route publication.
| Scenario | Independent observation | Wrong result to exclude |
|---|---|---|
| A late signal from an old child | Current invocation and actual socket | Readying a replacement from stale proof |
| Session loss with the old process alive | Old process and current member counts | Claiming a global execution cap |
| One selected suffix conflicts | Complete Service and ownership | Publishing a partial Service |