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
You might think that this request will timeout after 60 minutes. Actually, this request will timeout after 100 seconds which is default connection timeout used by HttpClient. The ReleaseAssetUpload.Timeout value you see being set above will create a CancellationToken which will cancel the request prematurely (see HttpClientAdapter.cs#L61) but it does not override the HttpClient timeout. And 100 seconds not enough time to upload a larger asset.
It is possible to override the HttpClient timeout with client.SetRequestTimeout(...), however this now applies to every request. If I SetRequestTimeout to 60 minutes, even a simple "list releases" or "create release" request will be allowed to run for 60 minutes before timing out! That is not appropriate.
To add insult to injury, if I set the HttpClient request timeout to something large, I can't even specify the cancellation-token style timeout on the short-lived requests so they will timeout in a reasonable timeframe. (because most Octokit requests do not expose the Timeout property)
My options currently are:
Ignore the ReleaseAssetUpload.Timeout (because it's useless), and constantly call SetRequestTimeout before each request with a reasonable time. (can't do this because apparently SetRequestTimeout can not be updated after the first request)
Set both the SetRequestTimeout and ReleaseAssetUpload.Timeout to comically large values, and create my own cancellation token's for every request with reasonable values. (can't do this, because most requests don't even allow you to supply a cancellation token)
However, in both of the above options it's clear that the built-in timeout logic in Octokit is not fit for purpose.
Code of Conduct
I agree to follow this project's Code of Conduct
The text was updated successfully, but these errors were encountered:
Just writing to say that both of the workarounds I'd come up with did not work, so actually the only solution is to just set an insanely large timeout for every request.
Describe the need
At the moment the timeout support is confusing and inadequate. Take the following method for example:
You might think that this request will timeout after 60 minutes. Actually, this request will timeout after 100 seconds which is default connection timeout used by
HttpClient
. TheReleaseAssetUpload.Timeout
value you see being set above will create a CancellationToken which will cancel the request prematurely (see HttpClientAdapter.cs#L61) but it does not override the HttpClient timeout. And 100 seconds not enough time to upload a larger asset.It is possible to override the HttpClient timeout with
client.SetRequestTimeout(...)
, however this now applies to every request. If ISetRequestTimeout
to 60 minutes, even a simple "list releases" or "create release" request will be allowed to run for 60 minutes before timing out! That is not appropriate.To add insult to injury, if I set the HttpClient request timeout to something large, I can't even specify the cancellation-token style timeout on the short-lived requests so they will timeout in a reasonable timeframe. (because most Octokit requests do not expose the Timeout property)
My options currently are:
Ignore the(can't do this because apparently SetRequestTimeout can not be updated after the first request)ReleaseAssetUpload.Timeout
(because it's useless), and constantly callSetRequestTimeout
before each request with a reasonable time.Set both the(can't do this, because most requests don't even allow you to supply a cancellation token)SetRequestTimeout
andReleaseAssetUpload.Timeout
to comically large values, and create my own cancellation token's for every request with reasonable values.However, in both of the above options it's clear that the built-in timeout logic in Octokit is not fit for purpose.
Code of Conduct
The text was updated successfully, but these errors were encountered: