In T233969#5806411, @ifried wrote:

I'm unable to see the behavior change when I tested on https://test.wikipedia.org/. Can someone look into this? Thanks! Tagging @Mooeypoo

This issue is happening when the link and text inside the link do not have the same revision number.
For case:

In T231990#5509114, @dom_walden wrote:

A particularly bad example is the link [[Olympia]] in the fourth sentence here: https://tr.wikipedia.org/w/index.php?title=%C3%89douard_Manet. In the revision details we attribute that link to a revision which does not even include the word "Olympia".
I believe when WikiWho is doing the diff between the revisions it is mixing up a [[ token from another link.

PR: https://github.com/wikimedia/WhoWroteThat/pull/139

In T241062#5789558, @Mooeypoo wrote:

Note: I'm fairly sure this will be a lot easier to do (if not outright fixed?) with the refactoring PR at https://github.com/wikimedia/WhoWroteThat/pull/128

In T230357#5790697, @JoKalliauer wrote:

So what do you consider as common for switch-files on commons?

In T230357#5788178, @Aklapper wrote:

In T230357#5787399, @HMonroy wrote:

This file contains a non-standard SVG format that it is not currently supported

@HMonroy: What does "standard" mean here exactly, apart from specs? https://tools.wmflabs.org/svgcheck/index.php states the file is valid, and it's harder to contribute a patch without knowing what the problem is, and it seems like you investigated the problem?
Looks like the problem is described in the task summary, however I'm still surprised by the use of the word "standard" here.

This file contains a non-standard SVG format that it is not currently supported . We did take a look at the code to see if we can add a message to let the users know about the lack of support. The system is not able to recognize SVG files that are not formatted as expected so it would take a great effort to add the logic to identify this particular use case.

PR: https://github.com/wikimedia/WhoWroteThat/pull/130

I added the $wgAllowRequiringEmailForResets check. Thank you for pointing that out @dom_walden!

@ifried what should I have in the placeholder when the message is only being posted on the User_talk page? If the note is being sent to the previous reviewer then it only gets posted on the reviewer's talk page. It does not get posted on the article's talk page. The current placeholder is: Write a helpful note for $reviewer and future reviewers. . Perhaps, I can just have Write a helpful note for $reviewer? Or we can have a more general message. Please let me know how to proceed. Thanks!

Pull request https://github.com/wsexport/tool/pull/212 has been submitted to solve T237029 as part of the solution to this task.

This pull request has been submitted to resolve ticket: https://github.com/wsexport/tool/pull/212

In T230455#5661483, @dom_walden wrote:

In T230455#5661232, @HMonroy wrote:

@dom_walden we reviewed your concern during standup and since it's not very likely to happen (it has not been reported by any user) @ifried decided that it is safe to leave it as is for now. This possible case has been there since the beginning. Thank you!

OK, thanks.
@HMonroy I am seeing something else now I'm afraid, which I didn't see before. Occasionally, afd tags get added twice to a page. See, for example, https://test.wikipedia.org/wiki/Dsjfklsdjl (for the first and third nomination). I don't know if you can reproduce.
In these cases, I see two calls made to api.php?action=pagetriagetagging. Less often, I also see two calls to api.php?action=edit&title=User_talk:$creator&....
I tend to also see errors popping up briefly, such as "Failed to notify author" or "Failed to apply tag".
Another issue. In the AfD form if I don't enter anything in the "Add details" section and press "Mark for deletion", I get a validation error ("Tag afd is missing required parameter"). However, if I click OK the AfD action continues.

@dom_walden we reviewed your concern during standup and since it's not very likely to happen (it has not been reported by any user) @ifried decided that it is safe to leave it as is for now. This possible case has been there since the beginning. Thank you!

@Barkeep49 thank you for your help debugging this issue!

I also was not able to replicate this issue. I have merged https://gerrit.wikimedia.org/r/535754 to help isolate what is happening when the next button is not advancing.

@dom_walden the AfD action behavior is related to https://phabricator.wikimedia.org/T231357. @MaxSem is Dom's concern likely in production?

@dom_walden Thank you for checking, the articleinfo hook has been removed. It should not be triggered for any action.

@DannyS712 I'm going to take a look. Please let me know if you have any new findings.