Use of outdated/cached page-count causes loading too few stargazers pages

[Byron]

When loading a repository repeatedly over the weeks (on MacOS Big Sur, Safari), it appears that it loads too few pages, causing some of the star gazer history to be missing.

This screenshot was taken 2020-09-14, yet the star history stops on 2020-09-12

When doing the same without cache, or in an incognito window, the amount of stars is correct.

It appears that the link header it relies on in this portion of the code gets to see a cached/outdated link field. Since I am in a beta version of a browser, this might even be a browser bug. For some reason, it doesn't even show the link header field.

Response
Access-Control-Allow-Origin: *
Vary: Accept, Authorization, Cookie, X-GitHub-OTP, Accept-Encoding, Accept, X-Requested-With, Accept-Encoding
Content-Security-Policy: default-src 'none'
X-XSS-Protection: 1; mode=block
Access-Control-Expose-Headers: ETag, Link, Location, Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Used, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-Type, Deprecation, Sunset
Referrer-Policy: origin-when-cross-origin, strict-origin-when-cross-origin
Cache-Control: private, max-age=60, s-maxage=60
Date: Mon, 14 Sep 2020 06:33:49 GMT
X-Content-Type-Options: nosniff
ETag: "937a4fc75daa7b180ad084c05e3aad35"
X-Frame-Options: deny
X-RateLimit-Reset: 1600066753
Server: GitHub.com
X-GitHub-Request-Id: 8C77:79B1:27E1F2:34A437:5F5F0ECC
X-RateLimit-Used: 25
Strict-Transport-Security: max-age=31536000; includeSubdomains; preload
X-RateLimit-Remaining: 4975
X-RateLimit-Limit: 5000
Status: 304 Not Modified

However, I wonder if it would be safe to load pages until we see one page with less than the maximum count of stars per page, 100 in this case. I would believe this is safe as in the worst case, we would load a page that has no stars yet, i.e. a project with 100 stars has one page, even though we would try to load two pages.
Maybe there are other ways to assure the cache is always fresh though.

When curling https://api.github.com/repos/Byron/gitoxide/stargazers?per_page=100&page=1, it indeed shows the correct link field (Link: https://api.github.com/repositories/136510559/stargazers?per_page=100&page=2; rel="next", https://api.github.com/repositories/136510559/stargazers?per_page=100&page=15; rel="last"), and the code to extract the amount of pages gives 15 as expected. So it really does appear to be a caching issue.

[seladb]

I'm sorry for the late response. Thanks for reporting this issue. To be honest, I don't think I saw this issue before. In the example you posted it seems that the Cache-Control header is 60 sec so the browser shouldn't keep the data more than that.

You mentioned you're using a beta version of a browser. Did you see the issue in non-beta versions as well?

[Byron]

I will keep an eye out for that - once BigSur gets officially released and this issue persists, I will let you know hopefully alongside additional information to help understand this.

Assuming it has nothing to do with the browser, I thought the only thing that can interfere with network requests is service workers. I saw one being used here, maybe that's something to check.

Edit: Thanks for the response :) - no matter how soon, it's always appreciated. I am happy this project exists! It works consistently from where I am sitting, while star-history does not. And the statistics are nice, too - a super useful tool to understand the growth of your projects better (as measured solely by stars :D)

[seladb]

thanks for the kind words, much appreciated! It's great to get feedback on things that work but more importantly on things that don't 😃

Please keep an eye and let me know if the problem persists. I'll try to take a look also.

[Byron]

I haven't noticed this issue anymore, let's close this one :).