You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
currently if no versions match, the request is retried (with 0,2,5,10 delay). but if the request was successful (2xx status) and no versions matched, retrying doesn't do anything except needlessly wait. it should fail fast and print a different message. for those, we basically have this failure tristate:
request succeeded (2xx) to valid url, no versions
request failed (>=4xx) to valid url, no versions
request failed to 'invalid' url (econnrefused, no dns resolution, ..), no versions
..should all say something different error-wise, and only the latter two cases should retry loop
e.g.:
case 1:
CAUTION: no version found for 'package',
urls:
- url 1
- url 2
case 2:
same as 1, but
CAUTION: no version found for 'package' (http code 403, Forbidden),
case 3:
CAUTION: invalid version urls for 'package',
urls:
...
(technically, case 3 and 2 can be folded if it doesn't make sense to make them distinct, but at least it should report the type of connection failure)
but this immediately runs into the issue of there actually being multiple urls and hence multiple requests to care about the statuscode for, so case 2 doesn't work. so perhaps instead:
CAUTION: 'message depending on failure type' 'package',
urls:
- url 1 (http code xxx, http code name (all this extra () on non-200 only?))
only printed when a version check fails to fetch valid versions (all three cases), with successes not printing anything except the current version list like right now, but printing this kind of output in the default mode.
the main benefit is currently the update-check is completely useless for failures in non-verbose mode (it hangs for almost 20s, then prints 'caution no versions', which is very unfriendly), requiring people to pass verbose to even see what url is queried (since it's not always as simple as 'the url= in the template'), and then also not saying why the query failed- http failures are distinct from regex matching failures. this should all have nice default output without extra modes, with the extra verbose mode only showing urls being fetched live (like currently) but not being needed ever in practice for anyone.
The text was updated successfully, but these errors were encountered:
currently if no versions match, the request is retried (with 0,2,5,10 delay). but if the request was successful (2xx status) and no versions matched, retrying doesn't do anything except needlessly wait. it should fail fast and print a different message. for those, we basically have this failure tristate:
..should all say something different error-wise, and only the latter two cases should retry loop
e.g.:
case 1:
case 2:
same as 1, but
case 3:
(technically, case 3 and 2 can be folded if it doesn't make sense to make them distinct, but at least it should report the type of connection failure)
but this immediately runs into the issue of there actually being multiple urls and hence multiple requests to care about the statuscode for, so case 2 doesn't work. so perhaps instead:
only printed when a version check fails to fetch valid versions (all three cases), with successes not printing anything except the current version list like right now, but printing this kind of output in the default mode.
the main benefit is currently the update-check is completely useless for failures in non-verbose mode (it hangs for almost 20s, then prints 'caution no versions', which is very unfriendly), requiring people to pass verbose to even see what url is queried (since it's not always as simple as 'the url= in the template'), and then also not saying why the query failed- http failures are distinct from regex matching failures. this should all have nice default output without extra modes, with the extra verbose mode only showing urls being fetched live (like currently) but not being needed ever in practice for anyone.
The text was updated successfully, but these errors were encountered: