User Details
- User Since
- Mar 25 2022, 7:00 PM (104 w, 6 d)
- Availability
- Available
- LDAP User
- Unknown
- MediaWiki User
- Brycehughes [ Global Accounts ]
Sep 29 2023
@MSantos just curious if this should be on your radar. It's not an urgent bug, but it is a bug, and would be nice to have it on someone's radar, even if they backlog it.
Sep 28 2023
Many thanks!
Sep 27 2023
Closed and re-filed as a bug report. No idea if that matters.
Sep 25 2023
Ah ok. Thanks for checking. I suppose this can just sit open for a bit. I have a workaround, it just involves me hitting the API 2-3 mores times than I normally would. If that's fine with WMF then I guess that's fine with me for now.
Sep 17 2023
Here are some more examples:
Sep 15 2023
@dcaro it works in my case. What a coincidence re the DNS stuff! Thanks all
Sep 14 2023
@fnegri Thanks. In my personal case, this tool https://toolsadmin.wikimedia.org/tools/id/commonsapi (e.g. https://commonsapi.toolforge.org/?image=Fall_in_Yukon%27s_Tombstone_Territorial_Park_%E2%80%93_Protected_areas_in_Canada_Q844692.jpg&thumbwidth=200) needs a restart.
@fnegri this seems to have knocked out a significant number of toolforge tools, if not all of them. I see a generic NGINX 504 error. You couldn't shed any light on this, could you?
Ditto for this commons api fork by @Sebkur
Sep 8 2023
Sep 7 2023
@MSantos I'm just curious. How do you get fix like this so quickly in to prod? Do you not have annoying QA engineers? I mean, this was so swift... how does it happen?
Seems to be working now @MSantos
Well for the sake of science... [insert me angrily yelling and saying this should be the top priority of the Wikimedia team]... let's see if they approve it on the Wikivoyage end
Actually @akosiaris I'm an idiot. I can cache bust right (re the CDN)? Is that just an edit? Would that bust the same cache as the one I hit through the rest-api? I.e would we double bust
Hmm ok thanks. I don't really notice anything out-of-the-ordinary in the article wikitext. Were I behind the CDN I could pare the article down and see if something is tripping the parser but, alas, I'm in front of it.
Jul 7 2023
@alexandru.c.ene per T341248 and @akosiaris, I believe this should be fixed now.
Jul 6 2023
@akosiaris Fair enough. Ah, the joys of caching. Thanks.
@akosiaris that was fast! Many thanks.
Hi @MSantos, any idea why this fails? https://en.wikivoyage.org/api/rest_v1/page/mobile-html/Toronto
Ah it appears perhaps one was cached and that they both fail. Any idea why? I didn't think the PCS endpoints were being deprecated (they're not marked as deprecated in the docs).
Jul 4 2023
@akosiaris Yep all clear now from Georgia (the country). However, this lasted much more than "several minutes". What do you think is the maximum expected time on the CDN cache purge? (FWIW I am impressed that you can even purge your CDN [individually?] so quickly... cool tbh)
Jul 2 2023
Ok, reopening this, because I think I've been able to re-create the issue. I'm in Tbilisi, Georgia, I updated a wikivoyage lede. The change does not show up in the "extract" field when I'm on my local router here. The change does show when I jump on my San Francisco-based VPN.
May 9 2023
@akosiaris Fair enough. I also highly doubt it's anything MITM related. There is something weird going on, but it's spurious, so I suppose we'll just have to wait and see, because I can't think of a good reproduction case (apart from writing my own module and template and dummy page and then vandalising it/reverting it while curling it via the REST API... oh but who has the time...). Thanks all who participated here. Sorry about the lack of -vvi output... quite ironically, i was initially curling it with -vvi (or similar) but didn't insert it in this bug report for the sake of simplicity (and I don't log my terminal output).
May 5 2023
@Bawolff We may be stuck for now, since I seem to have resolved the problem at my Belgian address but resetting my router, and I am in currently in Lisbon until next week (where the error does not seem to occur). But, let me give it another shot next week when I'm back in Belg and if I see it again I'll make sure to include the headers.
May 4 2023
@akosiaris update: the user who reported seeing the issue from the Netherlands also reported that restarting their wifi router fixed the problem. This is really... something.
Home network (Airbnb). Get this: restarting the home wifi router fixed it.
May 3 2023
So, wild guess, but an ISP might interpret s-maxage=1209600 themselves and do their own caching based on that. If true, then... ugh. If this is true, then we could just do the standard "blame Huawei" and move on :/
@akosiaris if I curl it from San Francisco (VPN) I don't see it. If I curl it from Belgium (no VPN) I see it. It's being seen by at least one other experienced editor at Wikivoyage as well. If it's not CDN... what could possibly be up with the geographical discrepancy? s-maxage=1209600, max-age=0??
@TheDJ I'm still seeing it (from Belgium): curl https://en.wikivoyage.org/api/rest_v1/page/mobile-html/East_Frisia/4502178 | grep 'Anorexia is fun' or just take a look at https://en.wikivoyage.org/api/rest_v1/page/mobile-html/East_Frisia/4502178 ... so I'm thinking a CDN cache invalidation might help.
May 2 2023
Was just thinking... if either @MSantos or @akosiaris might try invalidating the CDN cache for East Frisia, that might remove the (pretty deeply) offensive content and then this could be backlogged for a bit pending further investigation, I suppose.
Mar 7 2023
@akosiaris thanks a ton for setting that up and running it. So, that solves my problem re Wikivoyage. I don't have any stake in Wiktionary like @Jaifroid, but I assume the same process would work there if the folks at Kiwix wanted to push for that. So, I think I can probably sign off on this thread now. Thanks again for your help with all this over all this time.
Mar 4 2023
@akosiaris absolutely no worries on response time. I know how it goes.
Feb 20 2023
@akosiaris The enwikivoyage community seemed rather nonchalant about my null-edit all pages proposal, and suggested rather I just defer to the WM dev team (i.e. you). So, here is the list of all pages: https://dumps.wikimedia.org/enwikivoyage/20230201/enwikivoyage-20230201-all-titles-in-ns0.gz . The only problem: it includes redirects. But do we care? It's still only about 62,000 pages (a drop in a the bucket compared to enwikipedia), so what are your thoughts on just using this list and then running a null-edit bot on it at a reasonable rate?
Feb 15 2023
@akosiaris someone suggested that just dummy/null editing really commonly used templates (e.g. {{geo}} and {{pagebanner}) on enwikivoyage might clear the caches for every page that uses that template via transclusion. Do you think this would work? Sure sounds a hell of a lot easier :)
@akosiaris would a simple text file of page names by line that need to be updated work for you? Working on getting approval for all articles (not pages) from the enwikivoyage community.
From your perspective that would mean either browser cache or some forward proxy you use to access the internet (and thus wikipedia as well).
@akosiaris Bizarre. I checked it with both curl and the browser. I don't think there's a forward proxy anywhere in the middle. However, I am in Vietnam at the moment... something fishy might have been going at the hotel (or even country wide). It's a head scratcher. If I notice it again, I'll try it with my VPN turned on and see if that makes a difference.
And yes null edits won't show up on watchlists, RecentChanges, etc. That's what a bot would run indeed. They have been somewhat controversial in the distant past and we would still need to get approval from the ewikivoyage community for running it, but depending on the number of pages you come up with and the proposed bot's rate, it's an argument that we can make somewhat convincingly I think.
I wonder if I could make the argument about running a null bot – slowly – on all pages, since they won't show up on people's watchlists. I'll propose it and gauge the degree of disgust and horror I receive in the feedback.
Feb 11 2023
@akosiaris Aaaaand now it seems to be be working... so maybe the CDN cache clear just takes some time? Okay, I'll working on getting a parseable list of pages to bot over. By the way, apparently there is a distinction between a "null edit" and a "dummy edit". I know what the latter is but I don't know what the former is. And apparently null edits won't show up on people's watchlists. Assuming you know what a null edit is, is that what the bot would run?
Feb 10 2023
@akosiaris so far as I can tell, even that link isn't working still. Compare the extract field in https://en.wikivoyage.org/api/rest_v1/page/summary/Khustain_Nuruu_National_Park to the lead section of https://en.wikivoyage.org/wiki/Khustain_Nuruu_National_Park . It's still missing "also known as Hustai National Park". Should I create a new ticket for this?
@akosiaris sorry about all the messages, but I notice that this still doesn't seem to be working for REST summary calls, although it does seem to work for mobile calls. For example, https://en.wikivoyage.org/api/rest_v1/page/summary/Khustain_Nuruu_National_Park . I recently updated this, noticed the summary does not update, did a dummy edit, and the summary still hasn't updated. Any idea why this might be? Is it possible to fix for summary calls as well? There's not much point in running a bot if the summary calls won't be updated.
@akosiaris Actually, the Wikivoyage folks noted that this might flood people's watchlists if we do it for every page. I'll work on get you a list of rarely-edited pages.
Feb 9 2023
@akosiaris what if we just did a dummy-edit bot for every page on Wikivoyage? It's Wikivoyage, not Wikipedia, so it's not huge. One page a second, let it run for a few days. Any thoughts on this? (Like I said I'd write the script myself but I'm Scala, Typescript... and Python when someone puts a gun to my head... so I'm probably not the best person for the job.) I can easily get you a list of Wikivoyage pages via db dumps.
@akosiaris We'll see how it goes over the the next few weeks. Really appreciate the offer re bot — I'll talk to the Wikivoyage folks about building a list. (I would write the bot myself my but I like to write my scripts in Scala because I'm crazy.) In any case, might contact you back (here?) if need be, and thanks again for your work on this. If you don't hear back, you can assume things are working well enough now.
Feb 8 2023
@akosiaris I'd also argue that naming things is this the hardest of all problems. But hey a topic for a different day.
@akosiaris yeah been in the industry for 15 years. Get both jokes. And understand the problem with cache invalidation. It's just going to be an f'ing pain in the ass to have to do dummy edits to like 15,000 barely looked-at Wikivoyage pages. But hey we're we're a lot better off than we were than we were 12 or 24 or 36 months ago so I'll take what I can get. Thanks for fixing this. (I haven't seen an improvement yet but assume this is moving through the deploy process.)
Feb 7 2023
@akosiaris How painful would a full cache purge be? It would be great to have the problem solved once and for all. And some Wikivoyage pages, for example, get very little attention. Yet we're still getting served content from like 2020.
Feb 1 2023
Jan 14 2023
This still fails for endpoints like https://en.wikivoyage.org/api/rest_v1/page/summary/Kaechon . And unfortunately in the summary case, there is no workaround by first supplying the latest revision id. I'm not sure what option there is other than re-opening this ticket, since the bug does not seem to be resolved. If its resolution is dependent on another ticket, then that's fine, but this one is by no means resolved and should be at least kept upon until it is fixed.
Jan 9 2023
@MSantos Thank you for your work on this, but I'm not sure this issue can/should be legitimately closed if it still occurs for seemingly many, many pages. That is, the bug does not seem to be resolved at all. I am tempted to re-open it.
Dec 10 2022
Dec 2 2022
@MSantos I see that https://en.wikivoyage.org/api/rest_v1/page/mobile-html/Uzbekistan is still delivering an ancient version of the page. The latest version of the page (as of this writing) can be seen by using the latest revision id: https://en.wikivoyage.org/api/rest_v1/page/mobile-html/Uzbekistan/4555712 . So it does not seem to be resolved in this case. Or do you think this is a separate issue worth a separate ticket?
Sep 2 2022
I'm encountering this with https://en.wikivoyage.org/api/rest_v1/page/mobile-html/Uzbekistan?footer=false which delivers a version of the page not around since March of this year. Would be great to see some movement on this.
Apr 19 2022
@vadim-kovalenko got it, thanks. I'll keep an eye on this ticket then.
Apr 15 2022
@vadim-kovalenko the article I tested was France. This seems to be fixed for a number of pages now, but still seems to be broken on many, such as Barcelona and Tokyo.
Mar 25 2022
As per the above comment, while investigating this via the V1 REST API, I noticed that if you remove Wikivoyage's Pagebanner template from the article and then re-add it, the extract field in the summary call re-populates permanently.