Skip to article

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.

A sequence across Server, Agent, Application and Yaogress follows assignment, startup, readiness reporting and complete service registration.
Publish public ingress after application readinessFor a public HTTP listener, Server sends the plan, Agent verifies the image and hands over the listening socket, and the application signals readiness after initialization. Server then checks the current plan, image and session before submitting the complete service to Yaogress.

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.

Keep each state within its proof boundary
ObservationEstablishesDoes not yet establish
App declaration committedCurrent intent is savedLaunch or predecessor termination
RUNNINGA Listener child is live and awaiting notificationApplication readiness
Eligible READYCurrent invocation and plan agreeIngress 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.

A decision flow checks Exact first, checks Any only on a miss, and selects one backend after a match. If neither matches, routing ends.
Consult Any only when Exact missesStart with Host. An Exact match fixes the service; Any is consulted only on a miss. Either successful branch leads to one backend choice. No match ends routing, and backend failure does not restart matching.

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.

  1. Check the declaration and scope

    Read the App, image and requested count, keeping current-membership scope explicit.

  2. Inspect the actual invocation

    Inspect plan adoption, running state, readiness and any stopping owner.

  3. 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.

Selected verification scenarios
ScenarioIndependent observationWrong result to exclude
A late signal from an old childCurrent invocation and actual socketReadying a replacement from stale proof
Session loss with the old process aliveOld process and current member countsClaiming a global execution cap
One selected suffix conflictsComplete Service and ownershipPublishing a partial Service