Excavator - Handle GitHub API rate limiting

[o-l-a-v]

Seems Excavator does not handle GitHub API rate limiting very well. Here is a run from Extras bucket:

https://github.com/ScoopInstaller/Extras/actions/runs/18555159620/job/52890740764

Autoupdating appflowy
The remote server returned an error: (403) rate limit exceeded.
URL https://api.github.com/repos/AppFlowy-IO/AppFlowy/releases is not valid

[o-l-a-v]

Or maybe it does, as it managed to update it anyway.

Could not find hash in https://api.github.com/repos/AppFlowy-IO/AppFlowy/releases
Downloading AppFlowy-0.10.1-windows-x86_64.zip to compute hashes!
VERBOSE: Requested HTTP/1.1 GET with 0-byte payload
VERBOSE: Received HTTP/1.1 response of content type application/json of unknown size
VERBOSE: Content encoding: utf-8
Downloading https://github.com/AppFlowy-IO/AppFlowy/releases/download/0.10.1/AppFlowy-0.10.1-windows-x86_64.zip (59.8 MB)...
Computed hash: 82b98f7943b2548b5b2e507ac6ff7b093801d842bbdf511ac1d1ee44ea5a6d44
Writing updated appflowy manifest

[z-Fng]

We still need to handle GitHub API rate limiting isuue.

as it managed to update it anyway.

When the hash extraction fails due to API rate limits, it will fall back to downloading. However, if it happens in version detection (checkver), it will fail directly.

~~Possible solution:~~

• ~~Use multiple tokens~~.
• ~~Obtain a higher rate-limit GitHub token?~~ currently: 5,000 requests per hour, 100 concurrent requests
• ~~Split the Main/Extras bucket into multiple buckets.~~

[z-Fng]

The solution I suggested earlier was going in the wrong direction.

From my tests, most issues were caused by retrieving hashes from GitHub API without token and hitting concurrent request limits (100 concurrent requests), rather than the hourly request limit.

The missing token issue will be fixed in https://github.com/ScoopInstaller/Scoop/pull/6535. After it's merged, I'll retest to see if we need to adjust the concurrency limits.