Page MenuHomePhabricator

$wgMFAnonymousEditing = true is sometimes not respected: cache?
Closed, DuplicatePublic

Description

Atlasowa pointed out that there is a "hole" between 2015-01-09 and 2015-01-24 where very few edits were seen on it.wiki from unregistered editors.

This corresponds to reports in January that clicking the pencil produced the old message requiring login, that purge fixed the issue on the individual page and that on January 24 the issue seemed gone.

I had discussed the matter briefly with bblack on #wikimedia-operations but we were unable to raise actionable evidence. I note that on January 9 there was a series of deployments for MobileFrontend, so it's possible that something happened.

How to prevent this from happening again? Also, is it happening again now, as the decrease in edits after the latest deployment (involving 22e06675dbd1d2630b0e602c782be35145e8b94d) suggests? Can that be verified by purging mobile caches on it.wiki now?

Event Timeline

Nemo_bis raised the priority of this task from to Medium.
Nemo_bis updated the task description. (Show Details)
Nemo_bis added subscribers: Florian, MaxSem.

iirc (please correct me @MaxSem if i'm false), our templates are cached (30 days?), so if there are big changes, it would require to purge caches (e.g. moving from CtaDrawer to CtaOverlay). Just moving a button seems not to be a change which is big enough to purge caches?

No, everything delivered via ResourceLoader will be refreshed in 15 minutes.

Ah, ok, thanks @MaxSem, so i think we can close this task?

Config variables for anonymous users are baked into the HTML of a page when you use getSkinConfigVariables which will stay cached for 30 days. You'll have to use the ResourceLoader hook to avoid this issue and bake it into the JavaScript ResourceLoader startup module.

22e06675dbd1d2630b0e602c782be35145e8b94d would have been deployed instantly so if you are seeing a decrease it's possible this had a negative impact on edits. Data doesn't lie.

We really can't purge varnish caches for these sorts of changes.

22e06675dbd1d2630b0e602c782be35145e8b94d would have been deployed instantly so if you are seeing a decrease it's possible this had a negative impact on edits. Data doesn't lie.

Maybe, but that's not what this report is about. This report is about users not being able to edit *at all* without logging in.

Some days from 2015-01-09 to 2015-01-24 (*before* that commit) saw *no* edits at all from unregistered users. Users reported that, in those days, the pencils were locked or required login once clicked.

Jdlrobson claimed this task.

I'm not sure what the requested action is here.

It's only Wikimedia's services and cache setup that will run into this problem . If you deploy anonymous editing you'll need some kind of JS workaround or a cache flush... this should be taken care of on a case by case basis as some projects may welcome a gradual roll out. This should be done as part of a card 'enable anonymous editing on x'

There is no doubt whatsoever that an actual and severe bug was present between 2015-01-09 and 2015-01-24, so I doubt "Invalid" is a valid closure. However, I've never had high hopes that someone would bother investigating it. I only filed it on behalf of Atlasowa, but he doesn't want to register in phabricator.

Mmm.. Also looks buggy just tried to get past through the first screen on Italian Wikipedia and couldn't do it on my nexus 5 (maybe a bug?)

ef4df377d947f630f52cf3686e59622fe55a965d went live on January 7 with 1.25wmf13, but the configuration change 96f5c000328561e1066c2f25096ab398111dbddd was only merged on January 24, so for two weeks the it.wiki configuration "disappeared".

That explains the "hole" of two weeks, but Jon's report still has to be explained.