Why does the raw file still show previous data?

[burekasKodi]

Select Topic Area

Question

Body

Hi,

I updated some files in my repository, and I need to get this updated data with the raw option.
But the data there still shows the old data, even few hours later.

What can be the reason for that?
How can I force it to be updated according the repo files?

[2MuchC0ff33]

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.

[burekasKodi]

Hi,
Thanks for your help.

It is a xml file, so first I just press the Raw option on the view file section. Then I tried copy the raw url in different browser on my windows also in mobile. I also tried connect to different internet connections. All gives the same previous last raw data.

Example for the difference:
One of the last changes from the last commit:
Raw:
https://raw.githubusercontent.com/burekasKodi/repository.burekasKodi/main/addons.xml

The file:
https://github.com/burekasKodi/repository.burekasKodi/blob/main/addons.xml

[2MuchC0ff33]

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.

[burekasKodi]

@2MuchC0ff33
Still the same.
I don't think that this time it is a cache issue since I have already tried with different browsers etc.

[burekasKodi]

@2MuchC0ff33
Update:
I have just checked this from another laptop I have and there it's ok. But on my other laptop and mobile (with different browsers) I'm still getting the old data.

[hagezi]

@burekasKodi @2MuchC0ff33
This is a github problem, I see the same behavior with other repositiries as well.

[RobloxianRoblox3200]

Unfortunately, I have the same thing, but if you use vipien, everything is kind of normal(

[hagezi]

I have the same problem in my repository, the RAW links show the status from yesterday although it has been updated several times in the meantime. The parameter ?v=1 does not bring any change.

https://github.com/hagezi/dns-blocklists

https://github.com/hagezi/dns-blocklists/blob/main/whitelist.txt

https://raw.githubusercontent.com/hagezi/dns-blocklists/main/whitelist.txt?v=1

Missing last line in RAW ...

[grantwinney]

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.

[Aerowinder]

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

[GladistonXD]

I'm also having the same problem, it hasn't been reported yet on:
https://www.githubstatus.com/history

[grantwinney]

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.

[2MuchC0ff33]

Thank you, everyone.

@burekasKodi @grantwinney @GladistonXD @Aerowinder

Please submit a Bug Report using this link, or if you feel it is specific to Git, you can find more information on reporting the bug to their mailing list from here.

[2Abendsegler]

I have the same problem. The raw.githubusercontent.com links show content from 48 hours ago. I reported a bug about 34 hours ago. However, the ticket for it is probably not visible to everyone. There are no results yet.

[umwrya16]

Any response from github to that ticket?

[hagezi]

Quite annoying, if anything, there seems to be a RAW cache update only every 24 hours in some regions.

[2Abendsegler]

Any response from github to that ticket?

No

[hagezi]

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

[burekasKodi]

@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.

[2MuchC0ff33]

I am glad it is working again for you @burekasKodi

[shawvip]

I am glad it is working again for you @burekasKodi

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

[Slach]

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

[hagezi]

For me, the Github "Cache" problem is back ...

[sushantr5]

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

[sushantr5]

This is first time I am using raw file link for my project. The client code downloads config file stored with this raw link. This is really frustrating to wait for fix of the issue.

[karsiong]

Same Issue here, The problem start from 7 FEB 2023

[GladistonXD]

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.

[hagezi]

@GladistonXD Where can I check the value?

[GladistonXD]

debug options/network/Refresh the page and click on the request/headers/response headers/cache-control

[shawvip]

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

[antn]

👋 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.

[Ash-IPRANOps]

My bad, I did further testing and this is what I just realized. the Raw data on the Github is working fine now, the reason I was still getting the old data, is because after this issue started, I switched to using "Gist" which is more private if I needed to keep a file to only people with that link, but because I start using that file and after I update it, apparently the raw file link change every time to new link, so it doesn't behave the same was as the raw in Github where the link remains the same. so every time I was checking that link in Gist, I was getting the old data, that is why I thought it was the same issue. so let me ask you this, is there a way to have the secret "raw" gist file link remains the same even after any update? Thank you in advance.

[antn]

@Ash-IPRANOps unfortunately not, each Gist revision changes the raw URL like you mentioned, so that isn't possible currently.

Edit: Actually, my apologies, you can remove the specific SHA in the url and do something like https://gist.githubusercontent.com/<username>/<gist-id>/raw/gistfile1.txt, and it will point to the most recent revision (cached for 5 minutes).

[Ash-IPRANOps]

Thank you antn, but I just found it possible, by altering the raw link for the file, it will be unique to the file regardless of the version

example: Raw link for file = https://gist.githubusercontent.com//<Random (to file) letters&numbers>/raw/<Random (to version) letters&numbers>/

Change it to = https://gist.githubusercontent.com//<Random (to file) letters&numbers>/raw/

and it will work.

[antn]

Ah yep, I just edited my comment at the same time you posted that :) Glad you figured it out!

[Ash-IPRANOps]

perfect, that is what I did, thank you for the follow-up :) cheers

[antn]

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.

[QuanWanxx]

Still encounter this bug today, seems not fixed.

[antn]

@QuanWanxx Please provide the output of this curl command so we can see what might be going wrong:

curl -svo /dev/null <your-raw-url-here> -H"fastly-debug:1"

[QuanWanxx]

Found the content in raw raw is updated after about 10 mintues.

[krystian3w]

A delay of 5-10 minutes is rather the norm (based on the list of filters for uBlock Origin).

As it was lower before, you may have fallen into one with repositories where MS recommends migrating files to its (own) "CDN" server.

[antn]

Yes, the cache is set to 5 minutes, so that's expected. The previous bug was that it was set to 24 hours, but that's now fixed.

[atnbueno]

It's still happening to me (6h-old file), but I've found a workaround:

• I cache the file I'm interested until the Last-Modified header of https://api.github.com/repos/{USERNAME}/{PROJECT}/commits/{BRANCH} changes
• When it does, I download that JSON and if the array files has an item where filename is the name of the file I want, raw_url will have the URL of the last version of the file.

HTH

[umwrya16]

Has the issue been fixed? It seems like resolved for me. My updates went through in minutes

[antn]

Hey folks, we're continuing to work with Fastly to make sure that our caches are properly cleared. I think that the majority of these cache problems should be resolved, but we are continuing to monitor to make sure that everything is properly cached.

[umwrya16]

Thank you for the update.

[vit9696]

Thanks for your hard work, but actually we still experience the issue. For some reasons GitHub Actions get the old version of our build script with MTOC_LATEST_VERSION="1.0.1" instead of MTOC_LATEST_VERSION="1.0.2", causing jobs to fail.

[antn]

@vit9696 thanks for reporting. I've tried something to bust the cache, can you try rerunning that job 1 more time and see if it works? If it does, it could help us narrow down what might be going on.

[vit9696]

@antn, restarted. It seems to be working actually, at the very least went past the usual crash place. Thank you for your hard work ^__^

[krystian3w]

I would have released a 1.0.3 beta for action testing.

[piotrek94692]

The issue is back, it worked for a while, but now it doesn't work again for whatever reason.
Both of my gists have cache-control of 86400 instead of 300.
https://gist.github.com/piotrek94692/160a6fc6b3d434915dc6cb9b65c03d46

[piotrek94692]

So now if I'd change anything, you'd have to wait 24 hours for it to update.
Someone screwed something up again.

[krystian3w]

Maybe fake param forces new version:

https://gist.githubusercontent.com/piotrek94692/160a6fc6b3d434915dc6cb9b65c03d46/raw/floppy.sh?_=260220231626
https://gist.githubusercontent.com/piotrek94692/160a6fc6b3d434915dc6cb9b65c03d46/raw?_=260220231626

[piotrek94692]

Well yes, that's what I'm using for the second script, though I'm using an URL shortener for the first script, so I can't use parameters, because they disappear after a redirect.

[krystian3w]

Depends on how the link shortener works, certainly some should be able to tighten the parameter.

On bit.ly I can change origin url with free account. Similar can have TinyURL but I guess for premium accounts only.

[antn]

Sorry about this folks. We had fixed the problem with raw files in repositories, but there appears to be an issue with Gists as you noticed. We've rolled this change back and the cache should be returning to 5 minutes.

[tadashi-aikawa]

Hi, I have encountered the same issue.

https://raw.githubusercontent.com/tadashi-aikawa/silhouette/master/manifest-beta.json returns the following. (as I expected)

But https://raw.githubusercontent.com/tadashi-aikawa/silhouette/HEAD/manifest-beta.json returns the following. (too old)

On the other hand, It returns correctly by curl "https://raw.githubusercontent.com/tadashi-aikawa/silhouette/HEAD/manifest-beta.json".

Best regards.

[tadashi-aikawa]

I cleared the browser cache as follows.

[antn]

Sorry about this! I've busted the cache for that file so it should be back to 5 minutes.

[tadashi-aikawa]

@antn
I can get it! Thank you for the quick support!

[krystian3w]

Can't flush/rebuild all cache from problematic period of time instead waiting for manual reports?

[antn]

Hi @krystian3w, we did purge the cache for everything that was affected, but there appears to be an issue with our CDN where a small percentage of files do not get purged from certain POPs. That's why I've also asked for curls with the debug headers so we can work with our CDN provider to troubleshoot what causes that small percentage to not purge correctly.

[Slackadays]

I'm getting the same issue again with a recent commit of mine where the updated asset isn't showing up to new visitors: Slackadays/Clipboard@f1a0141

Would you mind purging the cache for mine too?

[antn]

@Slackadays The cache is set for 5 minutes, so that recent commit probably was too recent. You likely saw the old image because it was still within that 5 minute cache time from the last time your browser requested that image.

[josippavicic]

I found a way to get the latest with the raw URL. You will need your commit hash of the file version you want. Then simply use the following format: raw_url = "https://raw.githubusercontent.com/{username}/{repository}/{commit hash}/{file_path}?v=1". In my case I am fetching the commit hash on every push so I always have the latest commit hash, thus I download the latest file version.

[Chimpaya]

Thanks. For anyone wondering, you can fetch latest commit hash by calling GET https://api.github.com/repos/:user/:repo/branches/:branchName

[remal]

Faced this issue many times recently. Adding ?v=... doesn't help. Is there any way to fix it?

[and7ey]

I am having the same problem, I've raised the ticket https://support.github.com/ticket/personal/0/2822358

[vammultipl]

I'm facing this issue all the time in my new repo. It takes up to a minute or two for the raw file to properly update after pushing changes.

[ibevers]

Also facing this issue. It would be great if max-age could be customized (at least temporarily) or reduced to ~5 seconds. I need to make many iterative changes to files and see how they render in a UI that refers to the raw version of those files, and even a 5 minute cache update delay slows me down a lot.

[irm-codebase]

Same issue here.

[SaremS]

Same issue - sometimes takes up to five minutes to update.