fix(compute/deploy): service availability #875
Conversation
JakeChampion
left a comment
There was a problem hiding this comment.
LGTM! I like that this now only happens on service creation and not each deploy
|
Question: I'm creating Fastly services in my application and found myself needing to do a similar status check. I was surprised to see that the service initially responds with 500 responses with a plain body "Internal Server Error" until (presumably) it gets things initialized. Is there a reason Fastly doesn't use |
|
Hi @bstewart00 Great question, I'm not sure why a 503 wasn't used. I'll enquire internally and see if I can find out the situation, because (agreed) the use of a 500 is not ideal. |
This PR includes the following modifications to the service availability check...
--status-check-codeto be used as the 'expected status code' within the service availability check.Screenshots
In the first screenshot, we can see the service availability check (eventually) received a non-500 status code, which signified the service was deployed to/available from the user's nearest Fastly POP...
When running the
fastly compute deploycommand a second time after we already deployed the first time, we see there is no service availability check executed...In the following screenshot, we can see the service availability check 'in-flight' (i.e. running) and that it contains a timeout which helps users to see that the CLI has not stalled...
In the following screenshot, we can see what happens when a timeout is reached. In the default case we're looking for a non-500 and so the WARNING message indicates this...
Whereas the next screenshot demonstrates how the WARNING message changes when the user sets the
--status-check-codeflag, which tells the CLI the user expects a specific status code from the endpoint being checked...Finally, the following screenshot demonstrates a contrived example where a user expects their application to return a 500 by setting
--status-check-codeand thus the service availability check finishes almost immediately (but this doesn't mean the service is available and has returned an explicit 500, it's more likely in this scenario that the app hasn't reached the user's nearest POP and so the lookup has failed with a "No service available")...