No, we do not. It was first reported on July 2, 2016. - There was a discussion about sandboxes and their possible usage as trash bins before final delete of articles, during Wikimania, a practice used by Wikimedia Poland. There might be a connection.

Summary: That example page uses Template:User sand box which now does not immediately update the "Sandboxes of $username" section anymore (Regression), happening at least since 2016-07-02.

@Anomie, @aaron: Any idea which code area's commits to check for? Or who's a good person to CC here? Thanks in advance. :-/

Cannot see anything in the change log but no idea what string to search for (last core commits before July 2016 mentioning [Template|Api][Ss]andbox in their commit messages are 7762a0ca and 43f4a05e and d42d8b9b; for [Qq]ueue that's 04086027 and 406d6a2b.)

This has nothing to do with the API, ApiSandbox, or TemplateSandbox. The issue here is that a user's "main sandbox" subpage in their user space is using a cached version of the {{Special:PrefixIndex/User:{{ROOTPAGENAME}}/sandbox/| hideredirects=1 |stripprefix=1}} on Template:Sandbox_subpages. My suspicion is that it was caused by rMW7730dee63b1d: Make transcluded special pages not disable cache in miser mode. allowing such transclusions to be cached at all. This would have been deployed to enwiki on June 28 with 1.28.0-wmf.7.

Since caching such transclusions was intentional to improve performance, there's a good chance this task will be declined. But I'll let @Bawolff and others make that determination.

Thanks for explaining, @Anomie!

This affects our user group's education program and is really important because we have built on this and we continue to escalate. I hope we will have it ready before the begin of our new courses.

Sorry, but I think the benefits of the change outweigh the drawbacks. I don't think we should revert.

Would it be acceptable to have something along the lines of:

"New sandboxes may take up to an hour to show up here. Purge [With purge linking to ?action=purge] this page to show most recent additions"

on the template?

If there is another way to provide our multi-sandbox functionality, please do, and we will follow.

• We have zero biting to newcomers (or felt as biting) from old users as we have time to mentor the new editors until the article publication.
• User space page creation is a single click straight forward process and not playing with the url address.
• Article publication is done by a single click, when sandbox is ready as an article.
• The common mistakes in moving a page from user space to article space have been eliminated.
• History of sandboxed edits is kept in the article.
• Manual creation of list of links to user space pages is bypassed.
• An article template is preloaded for each new sandbox, i.e. having already put the citation ref magnet under the proper section.
• Senior citizens and non computer literated people do edit as they have to adapt to less new stuff to remember.
• Adding one more step in the process is one more memory we have to build in our new learners as well as to explain to everyone we expect to come back what they have learned does not work and push them to give up in case they do not read the new addition to the template explaining the extra step needed.
• Delayed caching has been affecting nested documentation in templates in the past, but not user space, which is a working place with immediade demands. Please provide metrics that user space lists updates delay the system.

@ManosHacker - indeed, would it not be enough to clearly say, in the template, something like "If you're not seeing a page you've just saved, CLICK HERE."?

If there is a single click button to do this it's fine. The path we have to follow now is click edit source, scroll, and click save (without changes). It would also help to use the 5 minutes delay instead.

In T139893#2593526, @ManosHacker wrote:

• Delayed caching has been affecting nested documentation in templates in the past, but not user space,

This is not correct, caching has always applied in the same way in both the Template and User namespaces. You weren't seeing caching behavior before on these specific user pages because the transclusion of Special:PrefixIndex had a side effect of disabling caching.

In T139893#2593869, @ManosHacker wrote:

If there is a single click button to do this it's fine. The path we have to follow now is click edit source, scroll, and click save (without changes). It would also help to use the 5 minutes delay instead.

See https://en.wikipedia.org/wiki/Template:Purge for example. It's currently a two-click process, although there's discussion in T143531 about the possibility of adding JavaScript to make it a single click again.

Change 307569 had a related patch set uploaded (by Aaron Schulz):
[WIP] Adapt the ParserOutput cache TTL when including special pages

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

In T139893#2595788, @gerritbot wrote:

Change 307569 had a related patch set uploaded (by Aaron Schulz):
[WIP] Adapt the ParserOutput cache TTL when including special pages

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

Looking at some profiling, I'm seeing ~275-350ms in parse for that same sandbox page in the description...so that would be like 10-15 minutes instead of 60. So don't expect much from that. I agree with bawolff about the cost/benefits...so disabling caching is not an option. I suppose one could also have subpage edits invalidate the parent page or something...but that's getting fairly specific to the prefixindex use case (without a big rationale).

Thank you for assisting, purging is an acceptable solution and I have commented to promote the option for single click purging. I will update sandbox instructions to include purging in order to immediately update the list.

I have added instructions to use purging and it works well in English. In Greek Wikipedia purging opens an additional tab in the browser and we are left with the same page opened twice (one updated, one not). Purging code needs an update in Greek Wikipedia. Having this settled, the case is closed.

Change 307569 merged by jenkins-bot:
Adapt the ParserOutput cache TTL when including special pages

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