Idea: a deterministic "ready" signal for Tye applications

As Tye commands (e.g. tye run) are long-running tasks and incur a variable amount of initialization time, it would be useful for automation purposes to be able to understand when those commands have “completed” (i.e. the application is running). Also, such a signal is best done in an asynchronous manner rather than require polling by the automation (which would then incur latency). There are a number of ways this can be accomplished (with varying amount of effort):

• Shortest term: write a definitive “ready” string to standard output. This is similar to the approach used by automation for ASP.NET applications which typically wait for a “listening on port…” string. The downside to this approach is that it can be complicated by localization efforts, terminal formatting, and output buffering.
• Medium term: publish the status of a Tye application via the Tye dashboard API. The downside to this approach is (1) knowing where and when the API endpoint is ready and (2) knowing when that status changes.
• Longer-term: provide an asynchronous mechanism to both identify running Tye applications as well as their state changes. This could be as fancy as using mDNS to advertise Tye applications on the network and then SignalR-style callbacks in the API endpoint for state changes.

[philliphoff]

In my case, I’m less interested in knowing the readiness of each individual service so much as the completion of the orchestration performed by Tye. That is, my automation purposes simply want to know when Tye thinks it’s done initializing all of the extension services, sidecars, and services.

Looking at the readiness of all services could work, but likely assumes knowledge of the application services (such as that they support readiness probes in the first place) and may not work in general. Even then, it would still be helpful to have a non-polling mechanism for notifications of state changes (to reduce the latency of the automation).

[goblinfactory]

A simple pattern that bypasses all these issues could be where Tye starts a queued-bus of some kind, then starts the services only after the bus is ready to accept messages, then it doesn’t matter if services are “ready” or not. They’ll process messages in the queue when they start. In a true distributed system, the fact that all the services have started does not tell you much at all about the state of the service from moment to moment, and if you’re polling the services, say … every 10 seconds, … and you have some process B, that absolutely MUST have dependent service A and D running before you send a message, then won’t that result in a kind of orchestration temporal coupling?