feat(compute/deploy): check service availability #860
Conversation
|
Here are some updated screenshots showing updated remediation messaging and status code responses. Success (404 Not Found) In the following screenshot notice the additional INFO log output to help guide the user when a non-2xx response is received. Success (200 OK) In the following screenshot notice there is no additional INFO log as we didn't get back a 4xx/5xx status. |
|
Here's another screenshot demonstrating a timeout (notice the WARNING message)... |
|
Here's another screenshot demonstrating the |
|
Here's another screenshot demonstrating the use of the The following screenshot uses both |
Problem
Users running
compute deployorcompute publishare immediately presented with a 'Service URL' which when clicked on by a user will typically return a500 Internal Servererror (as the user's application is still being deployed across Fastly's global network).Solution
Ping the Service URL until an appropriate response is received.
Notes
The implementation checks for a non-500 response and if it gets one within the specified timeout it will show a 'green tick' to indicate the service URL will work when visited.
The reason we've chosen this approach, rather than checking for a
200 OKfrom the service URL, is that we don't control a user's service and so a 4xx status code for the root path/of a service might be a completely valid response!Whereas we feel fairly confident that a
500 Internal Servererror is unlikely to be expected behaviour for anyone's service.We also ensure our messaging asks users to check their DNS if they have defined a custom domain, as some users will specify a custom domain and activate a service via the CLI and only then will setup the DNS to point to Fastly.
This is an interim solution until we have either an API or HTTP response header that helps us identify service availability.
Refer to the following 'example output' gif and see also the updated screenshots in the below thread.