oversight-wp wrote:

Typo : Suppressed edit is #283300452, not #283300459 (which was a revert of the addition)

I'm not seeing anything out of the ordinary viewing the diff provided while logged out. http://en.wikipedia.org/w/index.php?title=Giacomo_Marini&diff=prev&oldid=283300459

It's _possible_ that there's some sort of database lag in play here, but it's unlikely. A screenshot might help here, as I still see this bug as a bit dubious.

Also, if certain users are seeing the suppressed content while logged out, view the page source in your browser and look at the bottom for something like <!-- Served by srvXX in 0.XXX secs. -->

This will tell you which server is serving the content that should be suppressed.

oversight-wp wrote:

<!-- Served by srv61 in 0.433 secs. -->

I could not re-created the problem earlier today when I looked at logged in with my FloNight account. But after Mailer Diablo reported seeing it while not logged in. I tried again with a different browswer (IE) logged out and could see the redacted material.

Sydney Poore (FloNight)

Confirmed this using Safari for Mac (Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_6; en-us) AppleWebKit/525.27.1 (KHTML, like Gecko) Version/3.2.1 Safari/525.27.1).

I wasn't able to confirm using Firefox, though I doubt this is browser-specific.

The bad content is displayed sporadically, but is definitely visible to logged out users.

http://en.wikipedia.org/w/index.php?title=Giacomo_Marini&diff=next&oldid=283300452 produced http://p.defau.lt/?QBb9y0rpLRj0d7Z_eSVOsQ

http://en.wikipedia.org/w/index.php?title=Giacomo_Marini&diff=prev&oldid=283300452 produced http://p.defau.lt/?ZDeWRHtYfu09sp4XSdPTkw

Appears to not be related to a specific server serving the content. srv61, srv187, and srv200 all exhibited the bad behavior.

Looks like it's simply being cached at the squids:

Date: Mon, 13 Apr 2009 14:38:33 GMT
Server: Apache
X-Powered-By: PHP/5.2.4-2ubuntu5wm1
Cache-Control: private, s-maxage=0, max-age=0, must-revalidate
Content-Language: en
Vary: Accept-Encoding,Cookie
X-Vary-Options: Accept-Encoding;list-contains=gzip,Cookie;string-contains=enwikiToken;string-contains=enwikiLoggedOut
;string-contains=enwiki_session;string-contains=centralauth_Token;string-contains=centralauth_Session
;string-contains=centralauth_LoggedOut
Content-Encoding: gzip
Content-Length: 7747
Content-Type: text/html; charset=utf-8
Age: 96881
X-Cache: HIT from sq38.wikimedia.org, MISS from sq34.wikimedia.org
X-Cache-Lookup: HIT from sq38.wikimedia.org:3128, MISS from sq34.wikimedia.org:80
Via: 1.1 sq38.wikimedia.org:3128 (squid/2.7.STABLE6), 1.0 sq34.wikimedia.org:80 (squid/2.7.STABLE6)
Connection: keep-alive

Note the page has not be *edited* since the day before this page was generated, and the suppression happened about an hour afterwards.

Should double-check to make sure:

1. Diff pages are not being server-cached without a revalidation requirement (to check page_touched)
2. Make sure page_touched is being updated on suppression.

...

page_touched timestamp on this page is 2009-04-13 23:12:21, which is some hours after both the page generation and the suppression, so that seems fine. Looks like the cache-control headers on the diff view are probably bogus.

(In reply to comment #6)

Looks like it's simply being cached at the squids:

Thinking about caches, could it be stuck in the diff cache?

(In reply to comment #7)

(In reply to comment #6)

Looks like it's simply being cached at the squids:

Thinking about caches, could it be stuck in the diff cache?

There should already be checks for that.

@brion:
For (1), the rev perms are check first before even looking at the cache each time.
For (2), page_latest is already updated. I did add a commit() in r49592 similar to Article.php's doPurge().

(In reply to comment #9)

@brion:
For (1), the rev perms are check first before even looking at the cache each
time.
For (2), page_latest is already updated. I did add a commit() in r49592 similar
to Article.php's doPurge().

Squid purge timing should be fixed in r49592