Last modified: 2014-01-09 20:20:17 UTC
As discovered today with the Wikidata weekly summaries run, MassMessage ignores the namespace if it is a interwiki link. Example; {{#target:Wikidata:Status updates|www.wikidata.org}} The message gets delivered to https://wikidata.org/wiki/Status_updates which then errors due to it being in NS_MAIN and not NS_PROJECT which was specified.
Change 97162 had a related patch set uploaded by Legoktm: Create a fresh Title object in the job https://gerrit.wikimedia.org/r/97162
I guess this might also affect Commons (https://meta.wikimedia.org/wiki/Distribution_list/Global_message_delivery ). It looks like this issue prevents MM from being used for most of the usual global message deliveries to village pumps, so it's great that we already have a patch, and a timely review and deployment would be useful.
Change 97162 merged by jenkins-bot: Create a fresh Title object in the job https://gerrit.wikimedia.org/r/97162
Greg, Sam, would it be possible to get this backported and deployed next week? Global message delivery basically won't work because of this.
Thanks for the quick fix. This probably didn't get caught because we only deployed to test.wikipedia.org and test2.wikipedia.org, instead of a project such as Wikidata or Commons, which share an interwiki prefix and a namespace name. This probably points to an area where a unit test might make sense? (Or additional test inputs?) Maybe. In any case, this bug is no longer PATCH_TO_REVIEW. I'll leave it to someone else to figure out what to set it to.
Kunal: Yeah, please prepare a backport to wmf5. And when would you be available to help with the deploy this week? We might be able to get this in tomorrow. (I assume the only bit that is needed to be backported is Gerrit change #97162.)
Change 98709 had a related patch set uploaded by Legoktm: Create a fresh Title object in the job https://gerrit.wikimedia.org/r/98709
Change 98709 merged by jenkins-bot: Create a fresh Title object in the job https://gerrit.wikimedia.org/r/98709
(In reply to comment #6) > Kunal: Yeah, please prepare a backport to wmf5. I've created a branch called '1.23wmf5' and cherry-picked the patch onto it.
This was deployed at some point.
Not fixed apparently, see https://meta.wikimedia.org/w/index.php?title=User_talk:Guillom&oldid=6668167 Glancing at the list of wikis, the first thing I notice is that for all the wikis in the "did not work" list (except for one), they all have namespaces that are also interwiki prefixes on meta. The lone exception is ttwiki, https://tt.wikipedia.org/wiki/%D0%9C%D0%B0%D1%85%D1%81%D1%83%D1%81:%D0%9A%D3%A9%D0%BD%D0%B4%D3%99%D0%BB%D0%B5%D0%BA/massmessage?uselang=en The weird thing about that is that link is to the correct page. The link on the failed commons delivery is missing the namespace, see https://commons.wikimedia.org/wiki/Special:Log/massmessage
I'm not able to see where the namespace is being lost, so here are the steps the data goes through. Maybe someone else will spot it. 1. Picked up by MassMessageHooks::storeDataParserFunction as a string 2. MassMessageHooks::verifyPFData validates that it is a valid title (checks !is_null( Title::newFromText ) ), but returns the original string 3. MassMessage::getParserFunctionTargets unserializes the string. 4. MassMessage::normalizeTargets simply re-arranges the list of targets, not modifying the string. 5. Back to SpecialMassMessage::submit, which feeds the result from normalizeTargets to MassMessageSubmitJob. 6. the SubmitJob creates a Title object, and submits a group of MassMessageJobs. 7. On meta, in MassMessageJob::__construct, there is "$this->title = Title::newFromText( $this->title->getPrefixedText() );", which was the original fix for this bug. It *should* do nothing when being run on meta. 8. When the job is executed on the target wiki, that line is run again. Title::getPrefixedText should return the entire title (including interwiki) except for any fragments (url anchors). By re-creating the title, the namespace should be re-parsed as a real namespace instead of an interwiki prefix. The issue: If the namespace is not an interwiki prefix, it is re-parsed correctly as can be seen by the successful deliveries. If the namespace is an interwiki prefix, it is still thought to be an interwiki prefix (I think), and the delivery fails since it is not interpreted as a namespace. My hunch is that somewhere step 8 isn't working as I expect it would.
At [[Special:Log/massmessage]] I currently see: --- 08:38, 9 December 2013 Delivery of "[[m:Special:MyLanguage/Tech/News/2013/49|Tech News: 2013-49]]" to Village pump (technical) was skipped because target was in a namespace that cannot be posted in --- This is pretty gross. "Village pump (technical)" should be "Wikipedia:Village pump (technical)". Not sure what's going on with "[[m:...]]"; that may be a separate bug. Ori: any chance you could take a look here?
Change 101808 had a related patch set uploaded by Legoktm: Add debug logging for bug 57464 https://gerrit.wikimedia.org/r/101808
Change 101808 merged by jenkins-bot: Add debug logging for bug 57464 https://gerrit.wikimedia.org/r/101808
Change 101810 had a related patch set uploaded by Legoktm: Add debug logging for bug 57464 https://gerrit.wikimedia.org/r/101810
Change 101810 merged by jenkins-bot: Add debug logging for bug 57464 https://gerrit.wikimedia.org/r/101810
Change 101814 had a related patch set uploaded by Legoktm: Store title as a job parameter https://gerrit.wikimedia.org/r/101814
Change 101814 merged by jenkins-bot: Store title as a job parameter https://gerrit.wikimedia.org/r/101814
Dan or Greg, is there any chance we can get this deployed this week? Because of this bug, we're still dependent on EdwardsBot for global message delivery, and EdwardsBot is planned to be retired from global delivery in 2 days. The sooner we can fully transition to MassMessage, the better :)
(In reply to comment #20) > Dan or Greg, is there any chance we can get this deployed this week? > > Because of this bug, we're still dependent on EdwardsBot for global message > delivery, and EdwardsBot is planned to be retired from global delivery in 2 > days. The sooner we can fully transition to MassMessage, the better :) I've been using MassMessage the whole time. Just replace the namespaces with 'Project:' (if this is not deployed within time).
(In reply to comment #21) > I've been using MassMessage the whole time. Just replace the namespaces with > 'Project:' (if this is not deployed within time). Is the canonical namespace name safe to use? If so, that's a handy workaround. :-) (In reply to comment #20) People continue to use EdwardsBot, both locally and globally. Bug 58962 is probably more pressing to get resolved, but this bug (bug 57464) is medium priority given the rather nasty side effect (failed deliveries). It can probably go out to Wikimedia wikis on Monday or Tuesday of this week. That'd be a question for Sam, Ori, or Aaron S., I imagine. There's also bug 54859 about adding an API module for MassMessage. This would help for the Signpost in particular given its use of LivingBot, in my estimation.
(In reply to comment #22) > (In reply to comment #21) > > I've been using MassMessage the whole time. Just replace the namespaces with > > 'Project:' (if this is not deployed within time). > > Is the canonical namespace name safe to use? Let's see: <https://meta.wikimedia.org/w/index.php?title=Special:Contributions/AnankeBot&dir=prev&offset=20121207114449&limit=39&target=AnankeBot>.
This went out to the rest of the sites with today's deployment and looks to be working fine: <https://en.wikipedia.org/w/index.php?title=Wikipedia:Sandbox&diff=prev&oldid=589970369>
