Example on testwiki: (testwiki admin access required to follow)

https://test.wikipedia.org/w/index.php?title=T205578_example&oldid=362683
SHOULD work when following https://test.wikipedia.org/w/index.php?title=T205578_example&oldid=362683&unhide=1 but fails

Works in DIFF view: https://test.wikipedia.org/w/index.php?title=T205578_example&type=revision&diff=362683&oldid=362682
When following https://test.wikipedia.org/w/index.php?title=T205578_example&type=revision&diff=362683&oldid=362682&unhide=1

Possible fixes include setting $audience = RevisionRecord::RAW at line 158 (to match the previous behavior where a $content was passed) or having the caller pass a constructor parameter to explicitly bypass the audience check.

I'm confused - if the user has the appropriate permissions, we should it be necessary to bypass the audience check? Am I missing something?

PoolWorkArticleView doesn't use per-user audience checks, it either does RAW or FOR_PUBLIC.

or having the caller pass a constructor parameter to explicitly bypass the audience check.

That would be nicer than using the content override option to signal whether an audience check should be done, which is the old behavior.

I'm a bit confused about pool counter key handling - audience does not seem to be factor in at all. Doesn't that mean that deleted content could be exposed to normal users if the timing is unfortunate enough so that one PoolWorkArticleView falls back to the result of another? Also, output for a non-private audience should not be written into parser cache but I don't see how that's guaranteed, either.

To answer my own question, fallback happens via looking up the other worker's result in the parser cache, so as long as the parser cache is used correctly, it's fine. And the parser cache is only used for current revisions and there the audience does not really matter. What's still confusing is that fallback()/getCachedWork() don't check the revision ID. I guess that's just a bug that has little impact because old revisions rarely get stampeded...

Change 463922 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[mediawiki/core@master] Add audience parameter to PoolWorkArticleView

https://gerrit.wikimedia.org/r/463922

Change 463922 merged by jenkins-bot:
[mediawiki/core@master] Add audience parameter to PoolWorkArticleView

https://gerrit.wikimedia.org/r/463922

Thank you, looks good - tested on Group2 projects.

@Daimona - worked for me (example here: https://test.wikipedia.org/w/index.php?title=T205578_example&oldid=362683&unhide=1 on testwiki) - goes right to the deleted text.

@Xaosflux Yes, because that's a single-revision view, but my comment was about diffs.

Diff: https://test.wikipedia.org/w/index.php?title=T205578_example&diff=next&oldid=362682&unhide=1 works for me as well.

For me, it doesn't:

This seems like it should be filed as a new task to me. As far as I can tell the diff issue doesn't seem to have been caused by the same change.

That's possible. I noticed them both at the same time, but tomorrow I'll do a git bisect to see if they share the same cause.

OK I'm following you now, you expect to see the before and after diff, plus the revision compiled text below. I don't see that either, but I can't recall if I used to see it in this view.

@Xaosflux indeed. I'm almost sure the content was shown, but anyway it doesn't make sense to show the header with the time without any content below.

Unless this is completely different from the issue I remember and I'm confused, this indeed used to show content - the wrong content. The page's current content, to be exact. And nobody apparently noticed for a decade or so :)

I guess it's not necessary to show the right content, but shouldn't at least the header be removed? I mean the "Revision as of 14:04, 29 July 2018" from the example above.

Probably best to file a separate task about that.