Wikipedia talk:Article alerts/Bugs/Archive/2017

Good article nominee no longer in the project

  Bug fixed

Filled by: Gorthian (talk · contribs)

Time filed: 03:10, 11 January 2017 (UTC)

Link(s):

• Nominated for GA on 18 December 2016
• Removal from DAB project on 19 December 2016

Comments: At the time of its GA nomination, Elastance still had a DAB project banner on its talk page. That banner was removed a day later, but the article has stayed in the daily article alerts for WP:WikiProject Disambiguation ever since. Doesn't it know when to quit? ;-)

There are no GAs or FAs in the DAB project, so that alert can be shut off, if necessary. — Gorthian (talk) 03:10, 11 January 2017 (UTC)

No idea why this is happening as the article is in no category/template that would cause it to be included part of the project. Last time something similar happened when some Wikipedia internals desynced and left a page in the category, but only if queried by the API. I purged the page cache (first time it threw and internal error -- may be that's telling of something). Let's see if it works tomorrow. If not, I'll manually check where it thinks it belongs. —  HELLKNOWZ  ▎TALK 11:50, 11 January 2017 (UTC)

Nope, it's still there, Hellknowz. But you gave me an idea, and I just made a null edit on both the article and the talk page. Let's see if that helps. — Gorthian (talk) 22:43, 11 January 2017 (UTC)

Well, the bot hasn't run yet, so there wouldn't be any changes until tomorrow. Also cache purge is pretty much the same as a null edit. —  HELLKNOWZ  ▎TALK 23:18, 11 January 2017 (UTC)

Still there. Hellknowz, in my experience, a null edit will often update a page more "thoroughly" than a cache purge, especially when template transclusions are involved. — Gorthian (talk) 05:16, 13 January 2017 (UTC)

Unless you do forcelinkupdate. But yeah, it's still there, so something weird is going on. I'll have to manually debug it and see which "list" it thinks the page is in. —  HELLKNOWZ  ▎TALK 11:40, 13 January 2017 (UTC)

Additional comments @Hellknowz: The former dab page Man 2 was deleted at AfD. It was then recreated as a redirect, which is now at RfD. It is showing up in Wikipedia:WikiProject Disambiguation/Article alerts in both places, even though as a redirect, it is not a dab page, nor does it have the {{WPDAB}} banner on its talk page. I bring this here because I thought it might shed some light for you on why the article alerts pick up on non-dab pages.

BTW, Elastance is still showing up on the alerts as a GAN. — Gorthian (talk) 22:39, 21 February 2017 (UTC)

Thanks for still keeping up with this and giving me a hint with the Man 2 page. I think I fixed the core issue [1].

Long explanation (and for my own record): So the thing with Elastance is that the page was once part of the project. The bot recorded that its talk page had the Template:WikiProject Disambiguation banner the first time it saw it (among all the other templates, categories, etc.). The bot saves this about all the pages, because it needs to know this once a page leaves the workflow to post it as "closed" to the correct projects (it might still update live for GAN, but others, like AfD, delete or move pages). The bug here was that the bot didn't clear the old saved entries when it looked at the live/active page again. It merged the lists. So it still had the WPDAB banner stored even if the live version didn't have it. This behaviour is because I once fixed a bug where pages tagged by a project after entering a workflow wouldn't get reported -- the bot only checked them once. So I made it check each time, in case it has new projects. And I didn't think to check what happens if a project de-tags the page. Anyway, I made it clear the previous lists if it is retrieving live ones for that page. Hopefully, I didn't break anything further.

Regarding Man 2, it's the same deal -- the page has the old lists stored, so it thinks it's part of WPDAB. In this case, AfD's closed, so the old lists are the only way it knows which projects it belonged to at the time. I can't get new lists because it will fail massively on non-existent pages, unless I add a whole "detect missing/moved/redirected/etc. pages" logic. Now, in this case, two different pages are seen by the bot as the same page, so it creates a bit of a mess thinking both are the same. If I keep the old lists, it shows up at RFD. If I delete old lists, it gets removed from AfD. But this is really rare, and there's no reliable fix. Anyway, it should get archived next run (taking away the closed AfD record too). But at least there shouldn't be any new ones.

I also excluded quality-related workflows from the DAB subscription [2], since I gather they are never relevant anyway. (Now to wonder how many things I broke by doing this mid-process.) —  HELLKNOWZ  ▎TALK 13:09, 22 February 2017 (UTC)

Hooray! And thank you for excluding the quality-related workflows. That's perfect. Now I'll keep my fingers crossed that nothing else is broken by this. — Gorthian (talk) 22:11, 22 February 2017 (UTC)

Missing PROD rationales

  Rare unfixable corner-case

Filled by: GeoffreyT2000 (talk · contribs)

Time filed: 02:10, 24 January 2017 (UTC)

Link(s): Wikipedia:WikiProject Video games/Article alerts

Comments: PROD rationales are sometimes not shown under "Proposed deletions" on Article alerts pages. Using the Video games page as an example, it says

• 23 Jan 2017 – Animanium (talk · edit · hist) was PRODed by Premeditated Chaos (t · c)

when it should say

• 23 Jan 2017 – Animanium (talk · edit · hist) was PRODed by Premeditated Chaos (t · c): non notable software extension.

GeoffreyT2000 (talk, contribs) 02:10, 24 January 2017 (UTC)

This happens when something in the user comments contains a blacklisted link. The bot makes a note at the bottom of the page:

Note: The report is stripped of custom user text, because one or more entries contained spam-blacklisted links that bot cannot post.

I haven't really extended it to detect which specific comment has which link in what form to only strip the offending ones. There was some sort of complication at the time that I don't recall now. —  HELLKNOWZ  ▎TALK 12:12, 24 January 2017 (UTC)

RM still showing even though it was closed

  Not a bug

Filled by: Hanif Al Husaini (talk · contribs)

Time filed: 12:48, 26 February 2017 (UTC)

Link(s): Wikipedia:WikiProject Indonesia/Article alerts, the requested move discussion

Comments: The requested move for Kapitan Cina is still there even though it was closed on 16 January 2017. Please fix. Hanif Al Husaini (talk) 12:48, 26 February 2017 (UTC)

(edit conflict) Hey, thanks for report. The page is still in Category:Requested moves, because it was literally placed on the page [3]. So the bot sees the page as being in RM workflow. I removed the category from the page. The bot should now see (next run) the entry as closed. —  HELLKNOWZ  ▎TALK 12:54, 26 February 2017 (UTC)

CfD discussion link section part removed

  One-time bug

Filled by: Pyxis Solitary (talk · contribs)

Time filed: 10:53, 3 December 2017 (UTC)

Link(s): [4]

Comments:

It deleted linking to discussion: https://en.wikipedia.org/w/index.php?title=Wikipedia:WikiProject_LGBT_studies/Article_alerts&diff=prev&oldid=813369311 Instead of the specific discussion it made alert link to the page as whole. Pyxis Solitary talk 10:53, 3 December 2017 (UTC)

Thanks for reporting the concern. The changes to the alert pages are not preserved by the bot. It replaces any edits you may make to the page. In other words, the page should not be manually edited. Unfortunately, that does mean that if the bot makes a mistake, then there's no real way to fix the issue other than do it every day (and trigger watchlists).

That said, the link was not included to begin with, because it never appears in the {{cfd all}}: [5]. Barring complex parsing, the bot has no idea where to point the link. It should be like this: [6]. I'll add this page for re-retrieval for bot's next run and that should hopefully update it correctly. —  HELLKNOWZ   ▎TALK 13:27, 3 December 2017 (UTC)

Of course, it did it again. Pyxis Solitary talk 15:30, 5 December 2017 (UTC)

Yeah, the bot doesn't visit the page again and so it didn't re-retrieve the what would now be correct section link. I had that feature before to manually tell it to revisit pages (User:AAlertBot/Reget), but I don't actually have that functionality at the moment. —  HELLKNOWZ   ▎TALK 15:59, 5 December 2017 (UTC)

Set the page to manually reget and looks fine now. Unfortunately, there's nothing I can do for user errors that get later corrected beyond reparsing every single page. —  HELLKNOWZ   ▎TALK 21:46, 5 December 2017 (UTC)