Is there a standard way to check server readiness?

[natebrennand]

The Prism server can take a while to finish starting up and become ready to accept requests depending on your spec. This can be problematic in a CI scenario if the test suite begins trying to hit the API server before it is ready.

For a project I'm contributing to, I developed a workaround that repeatedly pings a declared route until it responds 2XX before starting the tests. This works, but isn't very reusable as it depends on that route.

My Q's:

1. Is there a better route for checking server readiness? Or to have the routes processed in a separate pre-startup step?

2. Would the project be open to adding a default "ready" route so that the script could be more reusable?

---

Example workaround: https://github.com/twilio/twilio-oai-generator/pull/128

Similar Q in discussions: https://github.com/stoplightio/prism/discussions/1840

[dbrudner]

+1 on this, this would be super useful

[the-csaba]

Alternative solution is to check the prism output until the Prism is listening on... message appears:

echo "Starting Prism server"
prism mock openapi.yaml >prism.log 2>&1 &
tail -f prism.log | sed 's/Prism is listening on// q'
echo "     Started"

[EdVinyard]

There isn't currently a standardized way to check Prism readiness via an HTTP request. If we were to implement this feature, I think we would introduce a "listener" on a different port from what Prism uses, to ensure there's never a conflict between the mocked/proxied API and Prism's readiness check. That is, it normally listens on 4010, so we might put a readiness check on 4011.

We'd be happy to accept patches to add this feature, but it's unlikely we (Stoplight) will be able to add this ourselves in the very near future. If anybody is inclined to contribute, I've left a bad, incomplete hack to add a really simple HTTP readiness check more-or-less as I described above in the readiness-check-hack branch (diff).

[RubenAtBinx]

If you have the option to adjust the api spec file, I would suggest to add a specific readiness health endpoint that can be probed with a normal http get request.