Thanks for your question @burekasKodi

I want to avoid repeating a step you’ve already tried. Before I proceed, please share the steps you’ve taken thus far.

Thanks for sharing more information @burekasKodi.

I wonder if the old data is still due to caching issues.

Can you use a unique query parameter to bypass the cache? As an example: https://raw.githubusercontent.com/burekasKodi/repository.burekasKodi/main/addons.xml?v=1

By bypassing the cache, the client will be forced to retrieve the new version rather than the cached version.

Please let me know what your thoughts are.

I’m having the same issue with this file:

https://github.com/grantwinney/hide-comments-everywhere/blob/master/sites/version.json

I’ve updated it several times, going back and forth between a couple values.

The “raw” version of the file remains unchanged after 14 hours. I’ve checked on two separate devices, tried ctrl+shift+r to bypass any local cache, loaded the page in an incognito window, etc.

What’s weirder is that the other json file I updated in the first commit is showing an updated raw file. It’s just this one that won’t change.

Also happening with one (at least) of my repos.

Mine finally updated about an hour ago. I haven’t made any more changes to it though, to see if subsequent changes show up after a few minutes as they normally do.

Edit: I made changes to the same files this evening, and after an hour only one of them has updated.

For me, the Github “Cache” problems seem to be fixed.

@hagezi @2MuchC0ff33
Yes, it does seems like it works again, but I don’t know for sure if it was because I pushed a new commit to the repo or not.

We hit the same issue
it looks was pause in invalidation caches inside some of CDN regions

For me, the Github “Cache” problem is back …

Same Issue here, The problem start from 7 FEB 2023

This varies from repositories the default of “Cache-Control” is “max-age=300” repositories with a delay of up to 24h show 86400=24 hours, I don’t know if this was a change in Github policy or if it is really a bug in the server.

I am facing the same issue now. Raw is pointing to older version.
How to fix it

It’s just a matter of time, just wait to the cache re updates the data

Help!!!!
Anyone report this issue to GitHub admin?
Now the cache max age become 86400 (24hours)

I think is a bug not policy, because the date and expire is still 5min difference and 24hours is not logic.

I used a VPN to change my IP to a different country. This way sometimes it work sometimes it does not. Even when you find a country that works the next time it may not work.
the raw file link also show different data version depending on the IP address.
for example a Canadian ip may show old data but an Indian ip will show the new data.

I have problems with the raw files as well. As far as I know it should take exactly 5 minutes to cache them, but why is it taking so long recently? Is it a Github issue or what?

EDIT
After the first push the RAW file has been updated immediately (even before than 5 minutes); however after the 2nd push the cache-control has changed to 86400 (24 hours). I hope it’s not a policy change…

I have the same issue with a gist, cache-control is 24 hours instead of 5 minutes.

Raw gist files have always been cached hard, but a workaround is to add ? and a random number to the end of the query.

I have used this to allow me to auto update computer craft scripts.
"/raw/?" .. tostring(math.random(0, 9999999)) (lua) is all i needed to do to work around the harsh cache limits.

Example:

https://gist.githubusercontent.com/Vam-Jam/e3da791dd81637dbc2b52e0034e358b7/raw Cached
https://gist.githubusercontent.com/Vam-Jam/e3da791dd81637dbc2b52e0034e358b7/raw?12367 Uncached unless you get the same random number twice

👋 Hi folks, GitHub engineer here. This was a bug with our caching in some cases – sorry about this! We’re working on resolving this and the cache should be back to normal soon.

This should be fixed now, thank you for reporting it. I’ve purged the cache so your raw files should be back to using max-age=300. Please let me know if you’re still seeing a longer expiry, and I can take a look.