"No RateLimit present in response" on Windows?

[mvriel]

I was trying to fix the build in phpDocumentor when I discovered that the problem was that we were repeatedly getting the "No Ratelimit present in response" error when using Phive in our Windows machines (see https://github.com/phpDocumentor/phpDocumentor/runs/7249978421 for an example).

At first I was like, it must be a ratelimit issue; but I cache the phive folders now and on Windows it gives this error. (Sidenote: for some reason the hash of the phive.xml is different on windows vs mac and linux; hence it doesn't use the cache created on linux and windows).

What could this issue be? We are using Phive 0.15.1

[theseer]

I'm not sure how this can be a windows only problem ;)

In general, the "No RateLimit present in response" is coming from an exception thrown when phive wants to ensure that, mainly when talking to Github, we are within our RateLimit and the response doesn't have a rate limit information set. See https://github.com/phar-io/phive/blob/master/src/shared/http/HttpResponse.php#L76.

HttpResponse is the result object from our CurlHttpClient, the response headers are parsed here: https://github.com/phar-io/phive/blob/master/src/shared/http/CurlHttpClient.php#L103. I cannot see why this would work differently on windows than on the other operating systems.

Regarding caching: A wild guess would be a difference in paths? Would be interesting to have a look, but I don't have much at right now...

[mvriel]

I wouldn't know either why it would be windows specific; but that is what the tests show :) The cache difference if probably a line ending issue. The hashing function hashes the file contents and windows uses, obviously, a different line ending (and 2 bytes instead of 1)

[mvriel]

I may have something; while working on the builds I noticed that the Windows instances of Github Action are incredibly slow. Would it be possible that Phive hits a network timeout, receives an incorrect / bad response and that is why we are seeing this?

[theseer]

Technically possible, but that should result in either a curl error or non-200 http response code. And we SHOULD cover that.

Am Freitag, 8. Juli 2022 schrieb Mike van Riel:

I may have something; while working on the builds I noticed that the Windows instances of Github Action are incredibly slow. Would it be possible that Phive hits a network timeout, receives an incorrect / bad response and that is why we are seeing this?

-- Reply to this email directly or view it on GitHub: https://github.com/phar-io/phive/issues/374#issuecomment-1179000304 You are receiving this because you commented.

Message ID: @.***

[mvriel]

A quick scan shows that at least on https://github.com/phar-io/phive/blob/dac3e6f4b895489cfb7e2be637a43de7e0e0e6b2/src/services/resolver/GithubAliasResolver.php#L98-L100, there is no verification whether the result succeeded and when I check https://github.com/phar-io/phive/blob/7f7f5fbf918ee84d67ce734d4f0bf3214f4b264a/src/shared/http/CurlHttpClient.php#L183-L185 I can see that any 4xx and 5xx response will also result in a valid response object without rate limit headers included.

I do not know whether this is the location that actually causes the issue described above; but the combination of these 2 locations will match the described behaviour if there is not another part of the code that will compensate for this

[theseer]

Good point. Let me debug this next week :)

[ravage84]

Likely related to https://github.com/phar-io/phive/issues/228

Ran into this today again with a fresh isntallation of 0.15.2 on Windows 10.