[Wikidata-bugs] [Maniphest] T360891: Wikibase Lua tracking sampling is broken
tstarling added a comment. We (Brad Jorsch and I) didn't want random numbers in Scribunto because it encourages an inefficient implementation of things like "spotlight" templates that show a random featured article from a list of such articles. We want to cache the output from Scribunto but then people will see the same random selection for months at a time, so users will inevitably try to defeat caching or incentivize purge requests. For this application I would suggest passing a random number in $setupOptions to LuaEngine::registerInterface(). Implement your own LCG <https://en.wikipedia.org/wiki/Linear_congruential_generator> which should be doable in 2 lines of code even though you only have floating point numbers. The multiplication needs to fit in the 53-bit mantissa of the floating point number without rounding, which is not a problem for say MINSTD m=2^31-1, a=48271, which gives a maximum base 2 logarithm of 47. Or just increment a counter and report every time the counter mod N is zero. Offset the counter at startup by a random number. If you actually wanted to unconditionally seed the global RNG, this would not be the right way to do it. Better to seed it in mw.executeModule() based on an additional parameter passed from PHP. os.clock() only looks attractive as a random number source because we've deliberately avoided providing better random number sources to Lua. TASK DETAIL https://phabricator.wikimedia.org/T360891 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: hoo, tstarling Cc: tstarling, Lucas_Werkmeister_WMDE, Aklapper, Michael, Danny_Benjafield_WMDE, Isabelladantes1983, Themindcoder, Adamm71, S8321414, Jersione, Hellket777, LennardHofmann, LisafBia6531, Astuthiodit_1, 786, Biggs657, karapayneWMDE, Invadibot, maantietaja, Juan90264, Alter-paule, Beast1978, ItamarWMDE, Un1tY, Akuckartz, Hook696, Kent7301, joker88john, CucyNoiD, Nandana, Gaboe420, lucamauri, Giuliamocci, Cpaulf30, Lahi, Gq86, Af420, Bsandipan, GoranSMilovanovic, QZanden, KimKelting, LawExplorer, Lewizho99, Maathavan, _jensen, rosalieper, Neuronton, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T357940: on Watchlist, wikidata edit appears as User talk edit
tstarling added a comment.
This happened because your talk page uses {{cite Q}}. It cites the Wikidata
item that was changed.
Wikidata item list from the edit page:
F41990390: wb dcheney.png <https://phabricator.wikimedia.org/F41990390>
Wikitext:
Might you have time and interest in helping me recruit between, say, two
and four people, including yourself, to be interviewed for {{cite Q|Q57451712}}, which is broadcasted Tuesday evenings, 6-6:30
PM on [[KKFI]]?
DB contents:
MariaDB [enwiki]> select * from recentchanges where rc_source='wb' and
rc_timestamp like '20240217%' and rc_params like '%Q57451712%'\G
*** 1. row ***
rc_id: 1743604758
rc_timestamp: 20240217161414
rc_actor: 215708414
rc_namespace: 3
rc_title: Dcheney
rc_comment_id: 462661687
rc_minor: 1
rc_bot: 0
rc_new: 0
rc_cur_id: 2683797
rc_this_oldid: 1187191193
rc_last_oldid: 1187191193
rc_type: 5
rc_source: wb
rc_patrolled: 2
rc_ip:
rc_old_len: 12592
rc_new_len: 12592
rc_deleted: 0
rc_logid: 0
rc_log_type: NULL
rc_log_action:
rc_params:
a:1:{s:20:"wikibase-repo-change";a:14:{s:2:"id";i:1698058114;s:4:"time";s:14:"20240217161414";s:7:"user_id";s:7:"5025563";s:11:"revision_id";s:10:"2079836628";s:9:"object_id";s:9:"Q57451712";s:4:"type";s:20:"wikibase-item~update";s:11:"entity_type";s:4:"item";s:7:"page_id";i:57368056;s:6:"rev_id";i:2079836628;s:9:"parent_id";i:1977948271;s:7:"comment";s:118:"/*
wbsetqualifier-add:1| */ [[Property:P2701]]: [[Q45432]],
[[:toollabs:quickstatements/#/batch/224651|batch
#224651]]";s:9:"user_text";s:9:"Awinkler3";s:15:"central_user_id";i:66232819;s:3:"bot";i:0;}}
...
MariaDB [enwiki]> select * from wbc_entity_usage where eu_page_id=2683797;
+---+--+---++
| eu_row_id | eu_entity_id | eu_aspect | eu_page_id |
+---+--+---++
| 110258265 | Q1058342 | O |2683797 |
| 110258266 | Q1058342 | L.en |2683797 |
| 229267246 | Q106864469 | T |2683797 |
| 229267247 | Q106864469 | L.en |2683797 |
| 110258267 | Q18126338| O |2683797 |
| 110258268 | Q18126338| L.en |2683797 |
| 94051069 | Q4233718 | L.en |2683797 |
| 94051070 | Q57451712| C |2683797 |
| 94051071 | Q57451712| O |2683797 |
| 94051072 | Q6331837 | T |2683797 |
| 94051073 | Q6331837 | L.en |2683797 |
| 229267245 | Q7976 | C.P424| 2683797 |
+---+--+---++
TASK DETAIL
https://phabricator.wikimedia.org/T357940
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: tstarling
Cc: tstarling, Aklapper, Dcheney, caldera, GhostInTheMachine, NavinRizwi,
ItamarWMDE, Akuckartz, DannyS712, lucamauri, Nattes, Taiwania_Justo,
Wikidata-bugs, geraki, Ltrlg
___
Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org
To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T288396: Re-start Wikibase test coverage reporting
tstarling added a comment. In T288396#8987843 <https://phabricator.wikimedia.org/T288396#8987843>, @hashar wrote: > MediaWiki core has `composer run phpunit:coverage-edit` which invokes `includes/composer/ComposerPhpunitXmlCoverageEdit.php` which looks similar to the CI script `phpunit-suite-edit.py` uses the same wrong assumption. Looks like it can be replaced by the MediaWiki core equivalent code. I have found T235031: phpunit:coverage-edit - Add configuration flag so it can replace phpunit-suite-edit.py <https://phabricator.wikimedia.org/T235031>. It's all very unsatisfying. I don't want to touch it because I don't like any part of it. I'd end up patching MediaWiki, PHPUnit, Quibble and integration/config/dockerfiles. A month later, my PHPUnit PRs would be rejected and we'd be back to square one. Maybe you can slip something like `if args.cover_extension == 'Wikibase':` into phpunit-suite-edit.py and I can pretend not to see it. TASK DETAIL https://phabricator.wikimedia.org/T288396 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: tstarling Cc: tstarling, WMDE-leszek, hashar, Lucas_Werkmeister_WMDE, Jdforrester-WMF, Aklapper, Reedy, Isabelladantes1983, Themindcoder, Adamm71, Jersione, Hellket777, LisafBia6531, Astuthiodit_1, 786, Biggs657, karapayneWMDE, Invadibot, maantietaja, Juan90264, Peteosx1x, Alter-paule, Beast1978, ItamarWMDE, Un1tY, Mgagat, Akuckartz, Totolinototo3, Hook696, Kent7301, Zanziii, Sadisticturd, joker88john, CucyNoiD, Nandana, Gaboe420, lucamauri, Giuliamocci, Cpaulf30, Lahi, Gq86, Af420, Bsandipan, GoranSMilovanovic, QZanden, LawExplorer, Lewizho99, Maathavan, _jensen, rosalieper, Neuronton, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T65015: [Bug] SpamBlacklist hook causes Wikibase LinkTitle api phpunit tests to fail
tstarling closed this task as "Resolved". tstarling claimed this task. TASK DETAIL https://phabricator.wikimedia.org/T65015 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: tstarling Cc: tstarling, Aklapper, Wikidata-bugs, aude, Lydia_Pintscher, daniel, hoo, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, ItamarWMDE, Akuckartz, darthmon_wmde, Rosalie_WMDE, Nandana, lucamauri, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, TerraCodes, _jensen, rosalieper, Scott_WUaS, Verdy_p, Jdforrester-WMF, Jackmcbarn, Mbch331, Jay8g ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T288396: Re-start Wikibase test coverage reporting
tstarling added a comment. > I think core's ExtensionsTestSuite should create one suite per extension, under a top-level extensions suite. Then CI could just run that suite, instead of trying to guess the path. Alternatively, you can just specify extensions/Wikibase as the path. It seems to work. TASK DETAIL https://phabricator.wikimedia.org/T288396 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: tstarling Cc: tstarling, WMDE-leszek, hashar, Lucas_Werkmeister_WMDE, Jdforrester-WMF, Aklapper, Reedy, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, Peteosx1x, ItamarWMDE, Mgagat, Akuckartz, Totolinototo3, Zanziii, Sadisticturd, Nandana, lucamauri, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T65015: [Bug] SpamBlacklist hook causes Wikibase LinkTitle api phpunit tests to fail
tstarling added a comment. Restricted Application added a project: Wikimedia-production-error. LinkTitlesTest passes now. But SetClaimTest::testAddingStatementUsingFederatedProperty fails. TASK DETAIL https://phabricator.wikimedia.org/T65015 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: tstarling Cc: tstarling, Aklapper, Wikidata-bugs, aude, Lydia_Pintscher, daniel, hoo, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, ItamarWMDE, Akuckartz, darthmon_wmde, Rosalie_WMDE, Nandana, lucamauri, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, TerraCodes, _jensen, rosalieper, Scott_WUaS, Verdy_p, Jdforrester-WMF, Jackmcbarn, Mbch331, Jay8g ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T288396: Re-start Wikibase test coverage reporting
tstarling added a comment. I don't know why mwext-phpunit-coverage is a shell script instead of being part of quibble. Maybe @hashar can explain why it was done that way. I couldn't find an explanation in T195918 <https://phabricator.wikimedia.org/T195918>. TASK DETAIL https://phabricator.wikimedia.org/T288396 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: tstarling Cc: tstarling, WMDE-leszek, hashar, Lucas_Werkmeister_WMDE, Jdforrester-WMF, Aklapper, Reedy, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, Peteosx1x, ItamarWMDE, Mgagat, Akuckartz, Totolinototo3, Zanziii, Sadisticturd, Nandana, lucamauri, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T288396: Re-start Wikibase test coverage reporting
tstarling added a comment. The way extension coverage works was not obvious to me and took a bit of time to figure out. - The Jenkins job `mwext-phpunit-coverage-docker-publish` runs quibble with --commands=mwext-phpunit-coverage - That is not an actual quibble command. Quibble interprets unknown commands as shell commands and runs them. - The relevant Dockerfile installs mwext-phpunit-coverage.sh from the integration/config repo as /usr/local/bin/mwext-phpunit-coverage - This shell script calls phpunit-suite-edit, which is a python script that edits core's suite.xml, removing the original coverage filter, and instead covering src/, includes/ and maintenance/ of the extension directory. - Then it runs phpunit with the positional argument $ext/tests/phpunit. This directory doesn't exist on Wikibase. Wikibase has an onUnitTestsList hook to declare the directories that actually have tests in them. If you omit the $ext/tests/phpunit argument, it runs 36438 tests (presumably all tests from all installed extensions). Actually it's unclear to me how CI can ever run only the tests from a specific extension. It looks as if non-coverage test jobs will always run tests from extension dependencies. I think core's ExtensionsTestSuite should create one suite per extension, under a top-level extensions suite. Then CI could just run that suite, instead of trying to guess the path. If I fix the test path, I still get "Warning: Incorrect filter configuration, code coverage will not be processed". This is probably because src/, includes/ and maintenance/ are all non-existent, and so no files are included in the coverage filter. Perhaps CI could get the list of directories to cover from some configuration file in the extension, instead of guessing. TASK DETAIL https://phabricator.wikimedia.org/T288396 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: tstarling Cc: tstarling, WMDE-leszek, hashar, Lucas_Werkmeister_WMDE, Jdforrester-WMF, Aklapper, Reedy, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, Peteosx1x, ItamarWMDE, Mgagat, Akuckartz, Totolinototo3, Zanziii, Sadisticturd, Nandana, lucamauri, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T338213: CI + Beta errors: Call to undefined method MediaWiki\Extension\CentralAuth\Hooks\Handlers\AbuseFilterHookHandler::onAbuseFilter-generateUserVars()
tstarling added a comment. It still needs a regression test. TASK DETAIL https://phabricator.wikimedia.org/T338213 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Lucas_Werkmeister_WMDE, tstarling Cc: tstarling, kostajh, daniel, Aklapper, Lucas_Werkmeister_WMDE, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, ItamarWMDE, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Jdforrester-WMF, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T332953: Migrate PipelineLib repos to GitLab
tstarling added a comment. Will the GitHub mirrors be switched over to replicate from GitLab? This is necessary for libraries like Shellbox that use a GitHub webhook to update Packagist. TASK DETAIL https://phabricator.wikimedia.org/T332953 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: tstarling Cc: BPirkle, Tgr, Eevans, Seddon, MSantos, kevinbazira, odimitrijevic, BTullis, Ottomata, calbon, fgiunchedi, WMDE-leszek, fkaelin, ItamarWMDE, elukey, KartikMistry, santhosh, Martaannaj, sbassett, bking, bd808, Ladsgroup, Krinkle, Legoktm, tstarling, Physikerwelt, dcausse, Jdrewniak, taavi, hnowlan, Michaelcochez, cjming, Jdforrester-WMF, dduvall, Aklapper, thcipriani, Bellucii32, Themindcoder, Stevemunene, Adamm71, Jersione, Itsmeduncan, Hellket777, Cleo_Lemoisson, Brielikethecheese, LisafBia6531, JArguello-WMF, Astuthiodit_1, Atieno, 786, EChetty, TheReadOnly, Biggs657, karapayneWMDE, toberto, joanna_borun, Simonmaignan, Invadibot, DAbad, MPhamWMF, Devnull, maantietaja, Juan90264, Muchiri124, Confetti68, Anerka, Alter-paule, Beast1978, CBogen, Un1tY, Nintendofan885, Akuckartz, Otr500, Hook696, WDoranWMF, Ddurigon, MJL, Kent7301, brennen, Mateo1977, EvanProdromou, joker88john, Legado_Shulgin, ReaperDawn, CucyNoiD, Nandana, NebulousIris, Namenlos314, aezell, skpuneethumar, Gaboe420, Zylc, Giuliamocci, Davinaclare77, Abdeaitali, Cpaulf30, 1978Gage2001, Techguru.pc, Lahi, Operator873, Gq86, Af420, Xinbenlv, Vacio, Sharvaniharan, Bsandipan, scblr, Xover, GoranSMilovanovic, SPoore, TBolliger, Chicocvenancio, Hfbn0, QZanden, EBjune, Tbscho, Taquo, LawExplorer, catalandres, Eginhard, Lewizho99, Zppix, JJMC89, Maathavan, TerraCodes, DDJJ, _jensen, rosalieper, Agabi10, PEarleyWMF, Neuronton, RuyP, Liudvikas, Scott_WUaS, Pchelolo, Karthik_sripal, Izno, Wong128hk, Luke081515, Bsadowski1, Niharika, Wikidata-bugs, Jitrixis, aude, Bawolff, Dbrant, Dinoguy1000, Gryllida, Lydia_Pintscher, faidon, Grunny, ssastry, scfc, Alchimista, Arlolra, csteipp, Mbch331, Jay8g, Krenair ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T332953: Migrate PipelineLib repos to GitLab
tstarling updated the task description. TASK DETAIL https://phabricator.wikimedia.org/T332953 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: tstarling Cc: BPirkle, Tgr, Eevans, Seddon, MSantos, kevinbazira, odimitrijevic, BTullis, Ottomata, calbon, fgiunchedi, WMDE-leszek, fkaelin, ItamarWMDE, elukey, KartikMistry, santhosh, Martaannaj, sbassett, bking, bd808, Ladsgroup, Krinkle, Legoktm, tstarling, Physikerwelt, dcausse, Jdrewniak, taavi, hnowlan, Michaelcochez, cjming, Jdforrester-WMF, dduvall, Aklapper, thcipriani, Bellucii32, Themindcoder, Stevemunene, Adamm71, Jersione, Itsmeduncan, Hellket777, Cleo_Lemoisson, Brielikethecheese, LisafBia6531, JArguello-WMF, Astuthiodit_1, Atieno, 786, EChetty, TheReadOnly, Biggs657, karapayneWMDE, toberto, joanna_borun, Simonmaignan, Invadibot, DAbad, MPhamWMF, Devnull, maantietaja, Juan90264, Muchiri124, Confetti68, Anerka, Alter-paule, Beast1978, CBogen, Un1tY, Nintendofan885, Akuckartz, Otr500, Hook696, WDoranWMF, Ddurigon, MJL, Kent7301, brennen, Mateo1977, EvanProdromou, joker88john, Legado_Shulgin, ReaperDawn, CucyNoiD, Nandana, NebulousIris, Namenlos314, aezell, skpuneethumar, Gaboe420, Zylc, Giuliamocci, Davinaclare77, Abdeaitali, Cpaulf30, 1978Gage2001, Techguru.pc, Lahi, Operator873, Gq86, Af420, Xinbenlv, Vacio, Sharvaniharan, Bsandipan, scblr, Xover, GoranSMilovanovic, SPoore, TBolliger, Chicocvenancio, Hfbn0, QZanden, EBjune, Tbscho, Taquo, LawExplorer, catalandres, Eginhard, Lewizho99, Zppix, JJMC89, Maathavan, TerraCodes, DDJJ, _jensen, rosalieper, Agabi10, PEarleyWMF, Neuronton, RuyP, Liudvikas, Scott_WUaS, Pchelolo, Karthik_sripal, Izno, Wong128hk, Luke081515, Bsadowski1, Niharika, Wikidata-bugs, Jitrixis, aude, Bawolff, Dbrant, Dinoguy1000, Gryllida, Lydia_Pintscher, faidon, Grunny, ssastry, scfc, Alchimista, Arlolra, csteipp, Mbch331, Jay8g, Krenair ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T299077: CI job wmf-quibble-selenium-php72-docker get a deadlock on `change_tag_def` (NameTableStore)
tstarling added subscribers: Ladsgroup, tstarling. tstarling added a project: MediaWiki-extensions-WikibaseClient. tstarling added a comment. I saw this at 896198 <https://gerrit.wikimedia.org/r/c/mediawiki/core/+/896198>. The test is flaky because the job is flaky. InjectRCRecordsJob has a transaction wrapped around the whole job since 3aa96d61e24885c8a8d303692aac0c424b675681 <https://phabricator.wikimedia.org/rEWBA3aa96d61e24885c8a8d303692aac0c424b675681> at @Ladsgroup's request. Reverting that change would probably fix the issue. Deadlocks are expected if transactions are long and complex. TASK DETAIL https://phabricator.wikimedia.org/T299077 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: tstarling Cc: tstarling, Ladsgroup, Nikerabbit, matmarex, kostajh, Aklapper, ItamarWMDE, Akuckartz, lucamauri, Wikidata-bugs, zeljkofilipin, Jdforrester-WMF ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T304515: PHP Warning: Cannot use a scalar value as an array
tstarling added a comment. Model: '/tmp/lcstore' ] ); $store->startWrite( 'en' ); $store->set( mt_rand( 1, 10 ), mt_rand( 1, 1000 ) ); $store->finishWrite(); I ran it with ab -n1 -c10 -v1 .../lcstore-model.php After about 2000 successful requests, the static array file was corrupted, and subsequent requests failed with `ParseError: syntax error, unexpected token "=>"`. The resulting file had 954, 87639 => 204, 34112 => 964, ]; 83 => 490, ]; I applied my patch, deleted the file, and ran the test again. Then all 1 requests succeeded and the resulting file was still parseable, with about 5700 lines. TASK DETAIL https://phabricator.wikimedia.org/T304515 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: tstarling Cc: tstarling, toan, Michael, Lucas_Werkmeister_WMDE, matmarex, RhinosF1, Krinkle, kostajh, Aklapper, Astuthiodit_1, Trngsh15, VPuffetMichel, karapayneWMDE, ycrepeau, Invadibot, Mengs21, Mohammadmalek554, Universal_Omega, maantietaja, EgbeRef, ItamarWMDE, Vaibhav0199, Akuckartz, keithbrianpadilla, Tinzawoo533, Saimongoltinio, WikimeSteve, ppelberg, Onmir, DannyS712, Nandana, marcella, Revansx, lucamauri, Mh-3110, Yahya, OhKayeSierra, Amorymeltzer, takidelfin, Lahi, Gq86, Necroarcano, Robinma, GoranSMilovanovic, Jayprakash12345, QZanden, enigmaeth, rohitt, merbst, LawExplorer, Wess, _jensen, rosalieper, Scott_WUaS, Srdjan, Dixtosa, Jrf, Husun1297, Wikidata-bugs, aude, Dinoguy1000, Swainr, Jdforrester-WMF, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T304515: PHP Warning: Cannot use a scalar value as an array
tstarling added a comment. I noticed such a parse error on https://integration.wikimedia.org/ci/job/wmf-quibble-selenium-php74-docker/9834/ : 2022-12-01 00:18:47 ff4e35fdc681 wikidb: [62aa69b10ac402af1dc9e46d] /index.php?title=Special%3ACreateAccount ParseError: syntax error, unexpected ''Buka menu samping dan ketuk $' (T_ENCAPSED_AND_WHITESPACE) #0 /workspace/src/includes/language/LocalisationCache.php(1044): LCStoreStaticArray->startWrite(string) #1 /workspace/src/includes/language/LocalisationCache.php(496): LocalisationCache->recache(string) #2 /workspace/src/includes/language/LocalisationCache.php(370): LocalisationCache->initLanguage(string) ... Looking at the debug log, I noticed that there are concurrent requests. LCStoreStaticArray::finishWrite() just writes to the output file with file_put_contents(), which is not safe for concurrent requests. There is a chance that other requests will see a partially written file. TASK DETAIL https://phabricator.wikimedia.org/T304515 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: tstarling Cc: tstarling, toan, Michael, Lucas_Werkmeister_WMDE, matmarex, RhinosF1, Krinkle, kostajh, Aklapper, Astuthiodit_1, Trngsh15, VPuffetMichel, karapayneWMDE, ycrepeau, Invadibot, Mengs21, Mohammadmalek554, Universal_Omega, maantietaja, EgbeRef, ItamarWMDE, Vaibhav0199, Akuckartz, keithbrianpadilla, Tinzawoo533, Saimongoltinio, WikimeSteve, ppelberg, Onmir, DannyS712, Nandana, marcella, Revansx, lucamauri, Mh-3110, Yahya, OhKayeSierra, Amorymeltzer, takidelfin, Lahi, Gq86, Necroarcano, Robinma, GoranSMilovanovic, Jayprakash12345, QZanden, enigmaeth, rohitt, merbst, LawExplorer, Wess, _jensen, rosalieper, Scott_WUaS, Srdjan, Dixtosa, Jrf, Husun1297, Wikidata-bugs, aude, Dinoguy1000, Swainr, Jdforrester-WMF, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T260735: Stop using is_resource()
tstarling closed this task as "Resolved". tstarling claimed this task. tstarling added a comment. This is fixed in core and deployed extensions. TASK DETAIL https://phabricator.wikimedia.org/T260735 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: tstarling Cc: tstarling, brion, Reedy, alex-mashin, Ricordisamoa, ssastry, TheDJ, Aklapper, MaxSem, Astuthiodit_1, G1964j, Zekwn, karapayneWMDE, the0001, Invadibot, Zabe, Selby, AndreCstr, maantietaja, XeroS_SkalibuR, ItamarWMDE, Akuckartz, RhinosF1, DannyS712, Nandana, Mirahamira, lucamauri, Lahi, Gq86, Jontheil, Markhalsey, GoranSMilovanovic, Jayprakash12345, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, freephile, Wikidata-bugs, aude, Nikerabbit, Jdforrester-WMF, Mbch331, Krenair ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T308443: Phan broken due to ResourceLoader namespace move
tstarling added a comment. I've uploaded updates for 35 extensions, to be merged shortly after the core patch is merged. I linked them to T308718 <https://phabricator.wikimedia.org/T308718> so that there wouldn't be too much bot noise here. TASK DETAIL https://phabricator.wikimedia.org/T308443 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: tstarling Cc: Daimona, Ladsgroup, Reedy, ItamarWMDE, Michael, RhinosF1, Krinkle, tstarling, kostajh, Aklapper, Lucas_Werkmeister_WMDE, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, Akuckartz, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Jdforrester-WMF, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T308443: Phan broken due to ResourceLoader namespace move
tstarling added a parent task: T308718: ResourceLoader namespace. TASK DETAIL https://phabricator.wikimedia.org/T308443 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: tstarling Cc: Daimona, Ladsgroup, Reedy, ItamarWMDE, Michael, RhinosF1, Krinkle, tstarling, kostajh, Aklapper, Lucas_Werkmeister_WMDE, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, Akuckartz, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Jdforrester-WMF, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T308443: Phan broken due to ResourceLoader namespace move
tstarling added a comment. I think my preferred solution is to combine options 1, 2: update extensions to use the new class name, but if any affected extensions need to support old versions of core, use @phan-suppress. TASK DETAIL https://phabricator.wikimedia.org/T308443 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: tstarling Cc: Daimona, Ladsgroup, Reedy, ItamarWMDE, Michael, RhinosF1, Krinkle, tstarling, kostajh, Aklapper, Lucas_Werkmeister_WMDE, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, Akuckartz, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Jdforrester-WMF, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T308443: Phan broken due to ResourceLoader namespace move
tstarling added a comment. Basically it looks like at least a day of my time wasted debugging issues specific to the dinosaur version of PHP we are running in production. Potential fixes: - Patch all affected extensions to use the new class name. The core patch would be reapplied and the extension patches would be immediately merged. Would break anything using phan without release branches. - Add @phan-suppress to all affected methods in extensions. - Patch phan. Wastes upstream's time with ancient PHP version issues, and probably incurs a rebase cost when reapplying the core patch, due to phan deployment delay. - Temporarily have the core class use the old name in its signatures, and suppress the phan issues which will occur due to core having enable_class_alias_support=false - Forget it for now. Rebasing in future will be complex, so this option probably adds half a day to the project. - Upgrade to PHP 7.4 in production. Could be done in a few days and we need to do it anyway. TASK DETAIL https://phabricator.wikimedia.org/T308443 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: tstarling Cc: Reedy, ItamarWMDE, Michael, RhinosF1, Krinkle, tstarling, kostajh, Aklapper, Lucas_Werkmeister_WMDE, Astuthiodit_1, Sgs, karapayneWMDE, Invadibot, caldera, maantietaja, NavinRizwi, Akuckartz, DannyS712, Nandana, Lahi, Gq86, Daimona, GoranSMilovanovic, Nattes, QZanden, LawExplorer, Iniquity, _jensen, rosalieper, Taiwania_Justo, Scott_WUaS, Wikidata-bugs, aude, geraki, Jdforrester-WMF, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T308443: Phan broken due to ResourceLoader namespace move
tstarling added a comment. When phan is checking for a signature match, it first checks whether the names match: if (!$overridden_parameter_union_type->isEqualTo($parameter_union_type) && That always fails in the case of an alias. Then if the target PHP version is 7.4+, it checks for what the PHP manual calls contravariance <https://www.php.net/manual/en/language.oop5.variance.php>: $is_exception_to_rule = (Config::get_closest_minimum_target_php_version_id() >= 70400 && $overridden_parameter_union_type->isStrictSubtypeOf($code_base, $parameter_union_type)) || That check passes for an alias. So Phan does not properly implement alias checks for class overrides, but it accidentally works for --target-php-version=7.4 due to the contravariance feature. TASK DETAIL https://phabricator.wikimedia.org/T308443 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: tstarling Cc: Reedy, ItamarWMDE, Michael, RhinosF1, Krinkle, tstarling, kostajh, Aklapper, Lucas_Werkmeister_WMDE, Astuthiodit_1, Sgs, karapayneWMDE, Invadibot, caldera, maantietaja, NavinRizwi, Akuckartz, DannyS712, Nandana, Lahi, Gq86, Daimona, GoranSMilovanovic, Nattes, QZanden, LawExplorer, Iniquity, _jensen, rosalieper, Taiwania_Justo, Scott_WUaS, Wikidata-bugs, aude, geraki, Jdforrester-WMF, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T308443: Phan broken due to ResourceLoader namespace move
tstarling added a comment. In T308443#7931024 <https://phabricator.wikimedia.org/T308443#7931024>, @Lucas_Werkmeister_WMDE wrote: > The patch includes a “ResourceLoaderContext72Hack” hack class, which is apparently supposed to work around T166010#5962098 <https://phabricator.wikimedia.org/T166010#5962098>. Perhaps that hack, whatever it is, doesn’t work in Phan? No, that issue is not relevant for Phan. I'm currently trying to figure out how to run Phan against this extension locally. For some reason it doesn't pick up Wikibase/vendor and then throws errors about all the classes from there being missing e.g. WikibaseLexeme.datatypes.client.php:8 PhanUndeclaredTypeParameter Parameter $options has undeclared type \ValueFormatters\FormatterOptions But the CI console does not show this package being installed so I'm not sure how it avoids the error. This is with MW_INSTALL_PATH set, without that variable phan just passes. TASK DETAIL https://phabricator.wikimedia.org/T308443 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: tstarling Cc: Reedy, ItamarWMDE, Michael, RhinosF1, Krinkle, tstarling, kostajh, Aklapper, Lucas_Werkmeister_WMDE, Astuthiodit_1, Sgs, karapayneWMDE, Invadibot, caldera, maantietaja, NavinRizwi, Akuckartz, DannyS712, Nandana, Lahi, Gq86, Daimona, GoranSMilovanovic, Nattes, QZanden, LawExplorer, Iniquity, _jensen, rosalieper, Taiwania_Justo, Scott_WUaS, Wikidata-bugs, aude, geraki, Jdforrester-WMF, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T306358: InvalidArgumentException: WikiPage constructed on a Title that cannot exist as a page: Special:NewEntitySchema (NewEntitySchemaTest::testNewSchemaIsNotCreatedWhenB
tstarling added a comment. In T306358#7885242 <https://phabricator.wikimedia.org/T306358#7885242>, @Lucas_Werkmeister_WMDE wrote: > `git bisect` says the first bad MediaWiki core commit is rMW1ae3b0ca8672: Allow ContentHandler to "override" non-existent actions <https://phabricator.wikimedia.org/rMW1ae3b0ca867222318f1ca78df7a6e1e31a9837e3> (I67c1ae9534 <https://gerrit.wikimedia.org/r/c/mediawiki/core/+/768842>, T303237 <https://phabricator.wikimedia.org/T303237>), which seems to have removed a condition around the `Article::newFromTitle( $title, $context )` call that’s crashing here. I didn't mention that commit in my fix because I believe the bug existed before that change, for actions that exist. TASK DETAIL https://phabricator.wikimedia.org/T306358 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: tstarling Cc: Jakob_WMDE, tstarling, ItamarWMDE, Umherirrender, Lucas_Werkmeister_WMDE, Daimona, Aklapper, Reedy, Fernandobacasegua34, Astuthiodit_1, Susie413113, 786, Suran38, Biggs657, karapayneWMDE, Invadibot, Lalamarie69, maantietaja, Juan90264, Alter-paule, Beast1978, Un1tY, SCIdude, Akuckartz, Hook696, darthmon_wmde, Rosalie_WMDE, Kent7301, pdehaye, joker88john, DannyS712, CucyNoiD, Nandana, Gaboe420, Giuliamocci, Cpaulf30, Lahi, Gq86, Af420, Bsandipan, Andrawaag, GoranSMilovanovic, Jayprakash12345, QZanden, YULdigitalpreservation, LawExplorer, Salgo60, Lewizho99, JJMC89, Maathavan, _jensen, rosalieper, Neuronton, Scott_WUaS, Wong128hk, MisterSynergy, Verdy_p, abian, Niharika, Wikidata-bugs, aude, Lydia_Pintscher, Jdforrester-WMF, Addshore, Mbch331, Jay8g ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T260735: Stop using is_resource()
tstarling added a comment.
For debug output, is_resource() is often appropriate, e.g.
if ( is_resource( $item ) ) {
return '[Resource ' . get_resource_type( $item ) . ']';
}
Also, for input handling where the input may be either a scalar or a stream,
there is currently no alternative to is_resource(), e.g.
if ( is_resource( $req['body'] ) ) {
curl_setopt( $ch, CURLOPT_INFILE, $req['body']
);
So that is also a correct usage of is_resource(). My core patch will ignore
such usages.
TASK DETAIL
https://phabricator.wikimedia.org/T260735
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: tstarling
Cc: tstarling, brion, Reedy, alex-mashin, Ricordisamoa, ssastry, TheDJ,
Aklapper, MaxSem, G1964j, Zekwn, the0001, Invadibot, Zabe, Selby, AndreCstr,
maantietaja, XeroS_SkalibuR, Akuckartz, DannyS712, Nandana, Mirahamira,
lucamauri, Lahi, Gq86, Jontheil, Markhalsey, GoranSMilovanovic,
Jayprakash12345, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS,
freephile, Wikidata-bugs, aude, Nikerabbit, Jdforrester-WMF, Addshore, Mbch331,
Krenair
___
Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org
To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T285987: Do not generate full html parser output at the end of Wikibase edit requests
tstarling added a comment. In T285987#7191372 <https://phabricator.wikimedia.org/T285987#7191372>, @Addshore wrote: > Adding #platform_engineering <https://phabricator.wikimedia.org/tag/platform_engineering/> to get some input and thoughts on this topic from mediawiki folks that know more about something that might be missing, or thoughts on implementation. It's more @daniel's area, but for what it's worth, I'd rather review this once there is a patch in Gerrit, since that will clarify things, and it sounds like it will be a pretty small change. TASK DETAIL https://phabricator.wikimedia.org/T285987 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: tstarling Cc: tstarling, Lucas_Werkmeister_WMDE, Michael, Tarrow, daniel, Krinkle, Addshore, Aklapper, Invadibot, maantietaja, Akuckartz, WDoranWMF, holger.knust, EvanProdromou, Nandana, Jony, lucamauri, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Vali.matei, _jensen, rosalieper, Agabi10, Scott_WUaS, Pchelolo, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T260179: prop=description should handle Chinese language variant correctly
tstarling added a comment. I edited the task description because the class name was incorrect. In production this is implemented in `Wikibase\Client\Api\Description`. I would like to know what is calling this API and whether it would be sufficient to add a variant parameter to the module. If a script calls the API from within a page context, I think the variant of the response should match the variant of the context page, which is not necessarily the same as the Accept-Language header. I would consider Accept-Language to be just for the UI, not for the API, unless there is a very good reason for doing otherwise. TASK DETAIL https://phabricator.wikimedia.org/T260179 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: tstarling Cc: tstarling, Aklapper, Cosine02, cooltey, Invadibot, LaMagiaaa, RuiyuShen, maantietaja, Naike, Akuckartz, eprodromou, Joye_Zhang, WDoranWMF, VulpesVulpes825, Sunny00217, 94rain, DannyS712, Nandana, Hamishcn, Amorymeltzer, Lahi, Gq86, BJ6123C7BTD, GoranSMilovanovic, lisong, Allthingsgo, QZanden, LawExplorer, Sethakill, dg711, _jensen, rosalieper, Agabi10, Taiwania_Justo, Scott_WUaS, Pchelolo, Fuzheado, Cwek, Wikidata-bugs, aude, jayvdb, zhuyifei1999, Shizhao, Mbch331, Liuxinyu970226 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T260179: prop=description should handle Chinese language variant correctly
tstarling renamed this task from "The ApiQueryDescription should handle Chinese language variant correctly" to "prop=description should handle Chinese language variant correctly". tstarling updated the task description. TASK DETAIL https://phabricator.wikimedia.org/T260179 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: tstarling Cc: Aklapper, Cosine02, cooltey, Invadibot, LaMagiaaa, RuiyuShen, maantietaja, Naike, Akuckartz, eprodromou, Joye_Zhang, WDoranWMF, VulpesVulpes825, Sunny00217, 94rain, DannyS712, Nandana, Hamishcn, Amorymeltzer, Lahi, Gq86, BJ6123C7BTD, GoranSMilovanovic, lisong, Allthingsgo, QZanden, LawExplorer, Sethakill, dg711, _jensen, rosalieper, Agabi10, Taiwania_Justo, Scott_WUaS, Pchelolo, Fuzheado, Cwek, Wikidata-bugs, aude, jayvdb, zhuyifei1999, Shizhao, Mbch331, Liuxinyu970226 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T240884: RFC: How to evaluate user-provided regular expressions
tstarling removed a project: Platform Engineering. tstarling added a comment. Yes, the RPC endpoint was added to support this use case. Use `MediaWikiServices::getInstance()->getShellboxClientFactory()->getClient()->call()`. TASK DETAIL https://phabricator.wikimedia.org/T240884 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: tstarling Cc: Base, Daimona, daniel, tstarling, Bawolff, Joe, WMDE-leszek, Volans, sbassett, Krinkle, Agabi10, Lucas_Werkmeister_WMDE, Addshore, Aklapper, Ladsgroup, Invadibot, maantietaja, Akuckartz, Demian, DannyS712, Nandana, kostajh, Lahi, Gq86, GoranSMilovanovic, RazeSoldier, QZanden, LawExplorer, _jensen, rosalieper, xSavitar, Scott_WUaS, Izno, SBisson, Perhelion, Wikidata-bugs, aude, GWicke, jayvdb, fbstj, santhosh, Jdforrester-WMF, Mbch331, Jay8g, Ltrlg, bd808, Legoktm, WDoranWMF, holger.knust, EvanProdromou, Pchelolo ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T227266: Find out why 'old revisions do not have edit links' selenium test is flaky on CI
tstarling lowered the priority of this task from "High" to "Medium". TASK DETAIL https://phabricator.wikimedia.org/T227266 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: tstarling Cc: tstarling, Nikerabbit, Addshore, Pablo-WMDE, Jakob_WMDE, Ladsgroup, WMDE-leszek, Rosalie_WMDE, Lucas_Werkmeister_WMDE, Michael, alaa_wmde, Aklapper, noarave, Invadibot, Lalamarie69, maantietaja, Alter-paule, Hazizibinmahdi, Beast1978, Un1tY, Akuckartz, Hook696, Kent7301, joker88john, CucyNoiD, Nandana, Gaboe420, Giuliamocci, Cpaulf30, Lahi, Gq86, Af420, Bsandipan, GoranSMilovanovic, QZanden, LawExplorer, Lewizho99, Maathavan, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T227266: Find out why 'old revisions do not have edit links' selenium test is flaky on CI
tstarling raised the priority of this task from "Medium" to "High". tstarling added a comment. Looks like this test was reenabled a couple of days ago, by https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/683914 . Since then it's been a constant nuisance, failing on maybe 20% of core patches. I don't understand why the test was re-enabled prior to proposed fix https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/690044/ being merged. TASK DETAIL https://phabricator.wikimedia.org/T227266 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: tstarling Cc: tstarling, Nikerabbit, Addshore, Pablo-WMDE, Jakob_WMDE, Ladsgroup, WMDE-leszek, Rosalie_WMDE, Lucas_Werkmeister_WMDE, Michael, alaa_wmde, Aklapper, noarave, Invadibot, maantietaja, Hazizibinmahdi, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T227266: Find out why 'old revisions do not have edit links' selenium test is flaky on CI
tstarling merged a task: T282674: AssertionError [ERR_ASSERTION] in item old revisions do not have an edit link. tstarling added subscribers: Nikerabbit, tstarling. TASK DETAIL https://phabricator.wikimedia.org/T227266 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: tstarling Cc: tstarling, Nikerabbit, Addshore, Pablo-WMDE, Jakob_WMDE, Ladsgroup, WMDE-leszek, Rosalie_WMDE, Lucas_Werkmeister_WMDE, Michael, alaa_wmde, Aklapper, noarave, Invadibot, maantietaja, Hazizibinmahdi, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T282674: AssertionError [ERR_ASSERTION] in "item old revisions do not have an edit link"
tstarling closed this task as a duplicate of T227266: Find out why old revisions do not have edit links selenium test is flaky on CI. TASK DETAIL https://phabricator.wikimedia.org/T282674 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: tstarling Cc: tstarling, Aklapper, Nikerabbit, Invadibot, maantietaja, Akuckartz, DannyS712, Nandana, Lahi, Gq86, Pablo-WMDE, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Jdforrester-WMF, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T282674: AssertionError [ERR_ASSERTION] in "item old revisions do not have an edit link"
tstarling added a comment. It's an old bug, but it seems to be failing a lot more often recently. T227266 <https://phabricator.wikimedia.org/T227266> has a long history of it being tweaked, skipped and unskipped. Apparently it's also flaky in production, but that doesn't seem like a reason to enable a flaky test. TASK DETAIL https://phabricator.wikimedia.org/T282674 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: tstarling Cc: tstarling, Aklapper, Nikerabbit, Invadibot, maantietaja, Akuckartz, DannyS712, Nandana, Lahi, Gq86, Pablo-WMDE, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Jdforrester-WMF, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T240884: RFC: How to evaluate user-provided regular expressions
tstarling added a comment. OK, I'm adding PHP execution to the service. TASK DETAIL https://phabricator.wikimedia.org/T240884 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: tstarling Cc: Base, Daimona, daniel, tstarling, Bawolff, Joe, WMDE-leszek, Volans, sbassett, Krinkle, Agabi10, Lucas_Werkmeister_WMDE, Addshore, Aklapper, Ladsgroup, Akuckartz, Demian, darthmon_wmde, DannyS712, Nandana, kostajh, Lahi, Gq86, GoranSMilovanovic, RazeSoldier, QZanden, LawExplorer, _jensen, rosalieper, xSavitar, Scott_WUaS, Izno, SBisson, Perhelion, Wikidata-bugs, aude, GWicke, jayvdb, fbstj, santhosh, Jdforrester-WMF, Mbch331, Rxy, Jay8g, Ltrlg, bd808, Legoktm ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T240884: RFC: How to evaluate user-provided regular expressions
tstarling added a comment. In T240884#6392690 <https://phabricator.wikimedia.org/T240884#6392690>, @Lucas_Werkmeister_WMDE wrote: > I wonder if T260330: PHP microservice for containerized shell execution <https://phabricator.wikimedia.org/T260330> could be used for this? (That task is apparently now in progress.) I'm not sure that's what you want. I'm doing shell execution by RPC, but it sounds like you just want RPC. Maybe a similar solution is needed? TASK DETAIL https://phabricator.wikimedia.org/T240884 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: tstarling Cc: Base, Daimona, daniel, tstarling, Bawolff, Joe, WMDE-leszek, Volans, sbassett, Krinkle, Agabi10, Lucas_Werkmeister_WMDE, Addshore, Aklapper, Ladsgroup, Akuckartz, Demian, darthmon_wmde, DannyS712, Nandana, kostajh, Lahi, Gq86, GoranSMilovanovic, RazeSoldier, QZanden, LawExplorer, _jensen, rosalieper, xSavitar, Scott_WUaS, Izno, SBisson, Perhelion, Wikidata-bugs, aude, GWicke, jayvdb, fbstj, santhosh, Jdforrester-WMF, Mbch331, Rxy, Jay8g, Ltrlg, bd808, Legoktm ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T255078: RuntimeException when trying to view history of [[c:Template talk:Wikidata Infobox]]
tstarling added a comment. The above exception is reproducible by going to the URL from the log entry, or by searching Commons for p77489. TASK DETAIL https://phabricator.wikimedia.org/T255078 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: tstarling Cc: tstarling, Samuele2002, Agusbou2015, Liuxinyu970226, toan, hoo, Rosalie_WMDE, Jakob_WMDE, Silvan_WMDE, Addshore, Tacsipacsi, Aklapper, Jimfhahn, Adidsone1, darthmon_wmde, DannyS712, Nandana, Phukettaxigroup, lucamauri, Lahi, Gq86, Pablo-WMDE, GoranSMilovanovic, Jayprakash12345, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Lydia_Pintscher, Jdforrester-WMF, Mbch331, Rxy, Jay8g, Krenair ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T255078: RuntimeException when trying to view history of [[c:Template talk:Wikidata Infobox]]
tstarling added a comment.
There's been two of these exceptions since I deployed the updated message.
They were from search rather than a diff. I wasn't able to reproduce it on the
diff page.
2020-06-11 03:13:09 [f1269b59-3ea0-4264-8c07-14ebcdd5f303] mw1413
commonswiki 1.35.0-wmf.36 exception ERROR:
[f1269b59-3ea0-4264-8c07-14ebcdd5f303]
/w/index.php?title=Special:Search=20=0=default=p77489
RuntimeException from line 51 of
/srv/mediawiki/php-1.35.0-wmf.36/extensions/Wikibase/lib/includes/Store/EntityLinkTargetEntityIdLookup.php:
Managed to lookup EntityId 'P77489' but got an unexpected type 'item' for
namespace '0'.
{"exception_id":"f1269b59-3ea0-4264-8c07-14ebcdd5f303","exception_url":"/w/index.php?title=Special:Search=20=0=default=p77489","caught_by":"entrypoint"}
[Exception RuntimeException]
(/srv/mediawiki/php-1.35.0-wmf.36/extensions/Wikibase/lib/includes/Store/EntityLinkTargetEntityIdLookup.php:51)
Managed to lookup EntityId 'P77489' but got an unexpected type 'item' for
namespace '0'.
#0
/srv/mediawiki/php-1.35.0-wmf.36/extensions/Wikibase/repo/includes/Hooks/HtmlPageLinkRendererEndHookHandler.php(237):
Wikibase\Lib\Store\EntityLinkTargetEntityIdLookup->getEntityId(Title)
#1
/srv/mediawiki/php-1.35.0-wmf.36/extensions/Wikibase/repo/includes/Hooks/HtmlPageLinkRendererEndHookHandler.php(161):
Wikibase\Repo\Hooks\HtmlPageLinkRendererEndHookHandler->doHtmlPageLinkRendererEnd(MediaWiki\Linker\LinkRenderer,
Title, HtmlArmor, array, RequestContext, NULL)
#2
/srv/mediawiki/php-1.35.0-wmf.36/includes/HookContainer/HookContainer.php(319):
Wikibase\Repo\Hooks\HtmlPageLinkRendererEndHookHandler::onHtmlPageLinkRendererEnd(MediaWiki\Linker\LinkRenderer,
Title, boolean, HtmlArmor, array, NULL)
#3
/srv/mediawiki/php-1.35.0-wmf.36/includes/HookContainer/HookContainer.php(131):
MediaWiki\HookContainer\HookContainer->callLegacyHook(string, array, array,
array)
#4
/srv/mediawiki/php-1.35.0-wmf.36/includes/HookContainer/HookRunner.php(2035):
MediaWiki\HookContainer\HookContainer->run(string, array)
#5
/srv/mediawiki/php-1.35.0-wmf.36/includes/linker/LinkRenderer.php(396):
MediaWiki\HookContainer\HookRunner->onHtmlPageLinkRendererEnd(MediaWiki\Linker\LinkRenderer,
Title, boolean, HtmlArmor, array, NULL)
#6
/srv/mediawiki/php-1.35.0-wmf.36/includes/linker/LinkRenderer.php(381):
MediaWiki\Linker\LinkRenderer->buildAElement(Title, HtmlArmor, array, boolean)
#7
/srv/mediawiki/php-1.35.0-wmf.36/includes/parser/LinkHolderArray.php(303):
MediaWiki\Linker\LinkRenderer->makeBrokenLink(Title, HtmlArmor, array, array)
#8
/srv/mediawiki/php-1.35.0-wmf.36/includes/parser/LinkHolderArray.php(178):
LinkHolderArray->replaceInternal(string)
#9 /srv/mediawiki/php-1.35.0-wmf.36/includes/parser/Parser.php(4907):
LinkHolderArray->replace(string)
#10 /srv/mediawiki/php-1.35.0-wmf.36/includes/parser/Parser.php(1656):
Parser->replaceLinkHoldersPrivate(string)
#11 /srv/mediawiki/php-1.35.0-wmf.36/includes/parser/Parser.php(651):
Parser->internalParseHalfParsed(string, boolean, boolean)
#12 /srv/mediawiki/php-1.35.0-wmf.36/includes/OutputPage.php(2114):
Parser->parse(string, Title, ParserOptions, boolean, boolean, NULL)
#13 /srv/mediawiki/php-1.35.0-wmf.36/includes/OutputPage.php(1863):
OutputPage->parseInternal(string, Title, boolean, boolean)
#14 /srv/mediawiki/php-1.35.0-wmf.36/includes/OutputPage.php(1794):
OutputPage->addWikiTextTitleInternal(string, Title, boolean, boolean)
#15 /srv/mediawiki/php-1.35.0-wmf.36/includes/OutputPage.php(4094):
OutputPage->addWikiTextAsInterface(string)
#16
/srv/mediawiki/php-1.35.0-wmf.36/includes/specials/SpecialSearch.php(575):
OutputPage->wrapWikiMsg(string, array)
#17
/srv/mediawiki/php-1.35.0-wmf.36/includes/specials/SpecialSearch.php(453):
SpecialSearch->showCreateLink(Title, integer, NULL,
class@anonymous/srv/mediawiki/php-1.35.0-wmf.36/extensions/CirrusSearch/includes/Search/FullTextResultsType.php0x7f9fdfa3bd30)
#18
/srv/mediawiki/php-1.35.0-wmf.36/includes/specials/SpecialSearch.php(179):
SpecialSearch->showResults(string)
#19
/srv/mediawiki/php-1.35.0-wmf.36/includes/specialpage/SpecialPage.php(580):
SpecialSearch->execute(NULL)
#20
/srv/mediawiki/php-1.35.0-wmf.36/includes/specialpage/SpecialPageFactory.php(634):
SpecialPage->run(NULL)
#21 /srv/mediawiki/php-1.35.0-wmf.36/includes/MediaWiki.php(307):
MediaWiki\SpecialPage\SpecialPageFactory->executePath(Title, RequestContext)
#22 /srv/mediawiki/php-1.35.0-wmf.36/includes/MediaWiki.php(986):
MediaWiki->performRequest()
#23 /srv/mediawiki/php-1.35.0-wmf.36/includes/MediaWiki.php(543):
MediaWiki->main()
#24 /srv/mediawiki/php-1.35.0-wmf.36/index.php(47): MediaWiki->run()
#25 /srv/mediawiki/
[Wikidata-bugs] [Maniphest] [Commented On] T252091: RFC: Site-wide edit rate limiting with PoolCounter
tstarling added a comment.
I hope you don't mind if I contradict my previous comment a bit, since my
thinking is still evolving on this.
One problem with using lag as the metric is that it doesn't go negative, so
the integral will not be pulled down while the service is idle. We could
subtract a target lag, say 1 minute, but that loses some of the supposed
benefit of including an integral term. A better metric would be updater load,
i.e. demand/capacity. When the load is more than 100%, the lag increases at a
rate of 1 second per second, but there's no further information in there as to
how heavily overloaded it is. When the load is less than 100%, lag decreases
until it reaches zero. While it's decreasing, the slope tells you something
about how underloaded it is, but once it hits zero, you lose that information.
Load is average queue size, if you take the currently running batch as being
part of the queue. WDQS currently does not monitor the queue size. I gather
(after an hour or so of research, I'm new to all this) that with some effort,
KafkaPoller could obtain an estimate of the queue size by subtracting the
current partition offsets from KafkaConsumer.endOffsets()
<https://kafka.apache.org/25/javadoc/org/apache/kafka/clients/consumer/KafkaConsumer.html#endOffsets-java.util.Collection->.
Failing that, we can make a rough approximation from available data. We can
get the average utilisation of the importer from the
rdf-repository-import-time-cnt metric. You can see in Grafana
<https://grafana.wikimedia.org/d/00489/wikidata-query-service?panelId=5=1=1m>
that the derivative of this metric hovers between 0 and 1 when WDQS is not
lagged, and remains near 1 when WDQS is lagged. The metric I would propose is
to add replication lag to this utilisation metric, appropriately scaled:
//utilisation + K_lag * lag - 1// where K_lag is say 1/60s. This is a metric
which is -1 at idle, 0 when busy with no lag, and 1 with 1 minute of lag. The
control system would adjust the request rate to keep this metric (and its
integral) at zero.
> With PID, we need to define three constants K_p, K_i and K_d. If we had
problem with finding the pool size, this is going to get three times more
complicated (I didn't find a standard way to determine these coefficients,
maybe I'm missing something obvious)
One way to simplify it is with K_d=0, i.e. make it a PI controller. Having
the derivative in there probably doesn't add much. Then it's only two times
more complicated. Although I added K_lag so I suppose we are still at 3. The
idea is that it shouldn't matter too much exactly what K_p and K_i are set to
-- the system should be stable and have low lag with a wide range of parameter
values. So you just pick some values and see if it works.
> We currently don't have an infrastructure to hold the "maxlag" data over
time so we can calculate its derivative and integral. Should we use redis? How
it's going to look like? These are questions, I don't have answers for them. Do
you have ideas for that?
WDQS lag is currently obtained by having an ApiMaxLagInfo hook handler which
queries Prometheus, caching the result. Prometheus has a query language which
can perform derivatives ("rate") and integrals ("sum_over_time") on metrics. So
it would be the same system as now, just with a different Prometheus query.
> I'm not sure "Retry-After" is a good header for 2xx responses. It's like
"We accepted your edit but "retry" it after 2 seconds". I looked at RFC 7231
and it doesn't explicitly say we can't use it in 2xx requests but I haven't
seen anywhere use it in 2xx responses. We might be able to find another better
header?
The wording in RFC 7231 suggests to me that it is acceptable to use
Retry-After in a 2xx response. "Servers send the "Retry-After" header field to
indicate how long the user agent ought to wait before making a follow-up
request." That seems pretty close to what we're doing.
In summary, we query Prometheus for //utilisation + lag / 60 - 1//, both the
most recent value and the sum over some longer time interval. The sum and the
value are separately scaled, then they are added together, then the result is
limited to some reasonable range like 0-600s. If it's >0, then we send it as a
Retry-After header. Then we badger all bots into respecting the header.
TASK DETAIL
https://phabricator.wikimedia.org/T252091
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: tstarling
Cc: Majavah, tstarling, Joe, Dvorapa, daniel, Krinkle, Aklapper, Jakob_WMDE,
Lydia_Pintscher, WMDE-leszek, darthmon_wmde, Addshore, Ladsgroup, Demian,
DannyS712, Nandana, kostajh, Lahi, Gq86, GoranSMilovanovic, RazeSoldier,
QZanden, LawExplorer, elukey, _jensen, rosalieper, D3r1ck01, Scott_WUaS, Jonas,
Izno, S
[Wikidata-bugs] [Maniphest] [Commented On] T252091: RFC: Site-wide edit rate limiting with PoolCounter
tstarling added a comment. Really the client has to wait every time, so there needs to be a delay hint header like Retry-After with every response. So it's not exactly maxlag=auto. TASK DETAIL https://phabricator.wikimedia.org/T252091 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: tstarling Cc: tstarling, Joe, Dvorapa, daniel, Krinkle, Aklapper, Jakob_WMDE, Lydia_Pintscher, WMDE-leszek, darthmon_wmde, Addshore, Ladsgroup, DannyS712, Nandana, kostajh, Lahi, Gq86, GoranSMilovanovic, RazeSoldier, QZanden, LawExplorer, elukey, _jensen, rosalieper, D3r1ck01, Scott_WUaS, Jonas, Izno, SBisson, Perhelion, Wikidata-bugs, Base, aude, GWicke, Bawolff, jayvdb, fbstj, santhosh, Jdforrester-WMF, Mbch331, Rxy, Jay8g, Ltrlg, bd808, Legoktm ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T252091: RFC: Site-wide edit rate limiting with PoolCounter
tstarling added a comment. This proposal is effectively a dynamic rate limit except that instead of delivering an error message when it is exceeded, we will just hold the connection open, forcing the bot to wait. That's expensive in terms of server resources -- we'd rather have the client wait using only its own resources. A rate limit has a tunable parameter (the rate) which is not really knowable. Similarly, this proposal has a tunable parameter (the pool size) which is not really knowable. You have to tune the pool size down until the replag stops increasing, but then if the nature of the edits changes, or if the hardware changes, the optimal pool size will change. I suggested at T202107 <https://phabricator.wikimedia.org/T202107> that the best method for globally controlling replication lag would be with a PID controller <https://en.wikipedia.org/wiki/PID_controller>. A PID controller suppresses oscillation by having a memory of recent changes in the metric. The P (proportional) term is essentially as proposed at T240442 <https://phabricator.wikimedia.org/T240442> -- just back off proportionally as the lag increases. The problem with this is that it will settle into an equilibrium lag somewhere in the middle of the range. The I (integral) term addresses this by maintaining a rolling average and adjusting the control input until the average meets the desired value. This allows it to maintain approximately the same edit rate but with a lower average replication lag. The D (derivative) term causes the control input to be reduced more aggressively if the metric is rising quickly. My proposal is to use a PID controller to set the Retry-After header. Clients would be strongly encouraged to respect that header. We could have say maxlag=auto to opt in to this system. TASK DETAIL https://phabricator.wikimedia.org/T252091 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: tstarling Cc: tstarling, Joe, Dvorapa, daniel, Krinkle, Aklapper, Jakob_WMDE, Lydia_Pintscher, WMDE-leszek, darthmon_wmde, Addshore, Ladsgroup, DannyS712, Nandana, kostajh, Lahi, Gq86, GoranSMilovanovic, RazeSoldier, QZanden, LawExplorer, elukey, _jensen, rosalieper, D3r1ck01, Scott_WUaS, Jonas, Izno, SBisson, Perhelion, Wikidata-bugs, Base, aude, GWicke, Bawolff, jayvdb, fbstj, santhosh, Jdforrester-WMF, Mbch331, Rxy, Jay8g, Ltrlg, bd808, Legoktm ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T240884: Standalone service to evaluate user-provided regular expressions
tstarling added a comment. There is https://pecl.php.net/package/re2 . It was written for PHP 5 and was never updated after its initial release in 2011, but we have the skills to update it for PHP 7 and review it for security. If we believe in RE2 then we shouldn't be afraid to invest in it. TASK DETAIL https://phabricator.wikimedia.org/T240884 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: tstarling Cc: tstarling, Bawolff, Joe, WMDE-leszek, Volans, sbassett, Krinkle, Agabi10, Lucas_Werkmeister_WMDE, Addshore, Aklapper, Ladsgroup, darthmon_wmde, DannyS712, Nandana, kostajh, Lahi, Gq86, GoranSMilovanovic, RazeSoldier, QZanden, LawExplorer, _jensen, rosalieper, D3r1ck01, Scott_WUaS, Izno, SBisson, Perhelion, Wikidata-bugs, Base, aude, GWicke, jayvdb, fbstj, santhosh, Jdforrester-WMF, Mbch331, Rxy, Jay8g, Ltrlg, bd808, Legoktm ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T238575: Wikibase test builds failing with “ERROR: 0 is not in the dispatch table”
tstarling added a comment. In T238575#5672789 <https://phabricator.wikimedia.org/T238575#5672789>, @Lucas_Werkmeister_WMDE wrote: > In `getCandidateClients()`, the return value ultimately comes from `IDatabase::selectFieldValues()`, implying that we have some `wb_changes_dispatch` rows where the `chd_site` is actually `0`. I’m not sure if that’s correct. It looks like there is such a row. From the debug log of the build you referenced: INSERT OR IGNORE INTO unittest_wb_changes_dispatch (chd_site,chd_db,chd_seen,chd_touched,chd_lock,chd_disabled) VALUES (0,'foowiki',0,'00',NULL,0) In the test: $coordinator->initState( [ 'foowiki' ] ); The parameter is supposed to be "an associative array mapping client wiki IDs to client wiki (logical) database names", so passing ['foowiki'] causes the wiki ID to be 0. I note that the test is running SQLite, is there a reason for doing that? I couldn't reproduce the error with SQLite locally, but I'm not sure what version was used in the test. The addQuotes() change causes an integer instead of a string to be inserted into chd_site. Then the SELECT is later done by comparing chd_site with a string: chd_site='0'. You can imagine SQLite getting confused about that. It would probably work to either cast $siteID to a string in initState(), or to have the test call initState() correctly in the first place, say $coordinator->initState( [ 'foowiki' => 'foowiki' ] ); TASK DETAIL https://phabricator.wikimedia.org/T238575 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: tstarling Cc: Anomie, tstarling, Addshore, Aklapper, Lucas_Werkmeister_WMDE, Hook696, Daryl-TTMG, RomaAmorRoma, 0010318400, E.S.A-Sheild, Iflorez, darthmon_wmde, alaa_wmde, Meekrab2012, joker88john, DannyS712, CucyNoiD, Nandana, NebulousIris, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Af420, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, WSH1906, Lewizho99, Maathavan, _jensen, rosalieper, Scott_WUaS, Jonas, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T198492: Create a maintenance script to drop rev_text_id and ar_text_id from the database.
tstarling added a comment. In T198492#5471572 <https://phabricator.wikimedia.org/T198492#5471572>, @Anomie wrote: > Maybe that was true 15 years ago, but update.php seems well-established now. No, it was never true. update.php has been used to drop fields since MW 1.5, 14 years ago, but there was no backlog of undropped fields at that time. update.php has always been the correct script in which to drop fields and tables. Obviously we should take care to avoid losing data. But that's the case whether the update code is in update.php or another script. TASK DETAIL https://phabricator.wikimedia.org/T198492 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: tstarling Cc: tstarling, Aklapper, Anomie, Jdforrester-WMF, Tgr, daniel, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, JJMC89, B20180, _jensen, rosalieper, Agabi10, Wikidata-bugs, aude, Mbch331, Ltrlg ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T202483: www.mediawiki.org showing: error:Unknown database 'wikidatawiki' on shard: s3
tstarling added a comment. BlobStoreFactory has a single LoadBalancer injected into its constructor, but allows the caller to choose the wiki ID in newSqlBlobStore(). So that's wrong. Wikidata just gets the BlobStoreFactory from MediaWikiServices::getBlobStoreFactory(), which doesn't allow you to specify the wiki ID and just gives a BlobStoreFactory with the LoadBalancer for the current wiki. BlobStoreFactory could take an LBFactory instead, which would allow newSqlBlobStore() to fetch the correct LoadBalancer.TASK DETAILhttps://phabricator.wikimedia.org/T202483EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: tstarlingCc: Addshore, Anomie, daniel, tstarling, Paladox, Aklapper, greg, Liuxinyu970226, Prtksxna, TerraCodes, Marostegui, Lahi, Gq86, GoranSMilovanovic, RazeSoldier, QZanden, LawExplorer, Liudvikas, Luke081515, Wikidata-bugs, aude, zeljkofilipin, KartikMistry, Mbch331, Rxy, Jay8g, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T202483: www.mediawiki.org showing: error:Unknown database 'wikidatawiki' on shard: s3
tstarling added a comment. Passing the wrong LoadBalancer into the SqlBlobStore constructor would have approximately this effect. The "previous.trace" is: #0 /srv/mediawiki/php-1.32.0-wmf.18/includes/libs/rdbms/loadbalancer/LoadBalancer.php(768): Wikimedia\Rdbms\LoadBalancer->reportConnectionError() #1 /srv/mediawiki/php-1.32.0-wmf.18/includes/Storage/SqlBlobStore.php(203): Wikimedia\Rdbms\LoadBalancer->getConnection(integer, array, string) #2 /srv/mediawiki/php-1.32.0-wmf.18/includes/Storage/SqlBlobStore.php(279): MediaWiki\Storage\SqlBlobStore->getDBConnection(integer) #3 /srv/mediawiki/php-1.32.0-wmf.18/includes/libs/objectcache/WANObjectCache.php(1246): Closure$MediaWiki\Storage\SqlBlobStore::getBlob(boolean, integer, array, NULL) #4 /srv/mediawiki/php-1.32.0-wmf.18/includes/libs/objectcache/WANObjectCache.php(1119): WANObjectCache->doGetWithSetCallback(string, integer, Closure$MediaWiki\Storage\SqlBlobStore::getBlob;1643, array) #5 /srv/mediawiki/php-1.32.0-wmf.18/includes/Storage/SqlBlobStore.php(284): WANObjectCache->getWithSetCallback(string, integer, Closure$MediaWiki\Storage\SqlBlobStore::getBlob;1643, array) #6 /srv/mediawiki/php-1.32.0-wmf.18/extensions/Wikibase/lib/includes/Store/Sql/WikiPageEntityRevisionLookup.php(206): MediaWiki\Storage\SqlBlobStore->getBlob(string) #7 /srv/mediawiki/php-1.32.0-wmf.18/extensions/Wikibase/lib/includes/Store/Sql/WikiPageEntityRevisionLookup.php(114): Wikibase\Lib\Store\Sql\WikiPageEntityRevisionLookup->loadEntity(stdClass) #8 /srv/mediawiki/php-1.32.0-wmf.18/extensions/Wikibase/lib/includes/Store/DispatchingEntityRevisionLookup.php(59): Wikibase\Lib\Store\Sql\WikiPageEntityRevisionLookup->getEntityRevision(Wikibase\DataModel\Entity\ItemId, integer, string) #9 /srv/mediawiki/php-1.32.0-wmf.18/extensions/Wikibase/lib/includes/Store/CachingEntityRevisionLookup.php(104): Wikibase\Lib\Store\DispatchingEntityRevisionLookup->getEntityRevision(Wikibase\DataModel\Entity\ItemId, integer, string) #10 /srv/mediawiki/php-1.32.0-wmf.18/extensions/Wikibase/lib/includes/Store/CachingEntityRevisionLookup.php(87): Wikibase\Lib\Store\CachingEntityRevisionLookup->fetchEntityRevision(Wikibase\DataModel\Entity\ItemId, integer, string) #11 /srv/mediawiki/php-1.32.0-wmf.18/extensions/Wikibase/lib/includes/Store/CachingEntityRevisionLookup.php(104): Wikibase\Lib\Store\CachingEntityRevisionLookup->getEntityRevision(Wikibase\DataModel\Entity\ItemId, integer, string) #12 /srv/mediawiki/php-1.32.0-wmf.18/extensions/Wikibase/lib/includes/Store/CachingEntityRevisionLookup.php(87): Wikibase\Lib\Store\CachingEntityRevisionLookup->fetchEntityRevision(Wikibase\DataModel\Entity\ItemId, integer, string) #13 /srv/mediawiki/php-1.32.0-wmf.18/extensions/Wikibase/lib/includes/Store/RevisionBasedEntityLookup.php(39): Wikibase\Lib\Store\CachingEntityRevisionLookup->getEntityRevision(Wikibase\DataModel\Entity\ItemId) #14 /srv/mediawiki/php-1.32.0-wmf.18/vendor/wikibase/data-model-services/src/Lookup/RedirectResolvingEntityLookup.php(51): Wikibase\Lib\Store\RevisionBasedEntityLookup->getEntity(Wikibase\DataModel\Entity\ItemId) #15 /srv/mediawiki/php-1.32.0-wmf.18/extensions/Wikibase/client/includes/LangLinkHandler.php(109): Wikibase\DataModel\Services\Lookup\RedirectResolvingEntityLookup->getEntity(Wikibase\DataModel\Entity\ItemId) #16 /srv/mediawiki/php-1.32.0-wmf.18/extensions/Wikibase/client/includes/LangLinkHandler.php(331): Wikibase\Client\LangLinkHandler->getEntityLinks(Title) #17 /srv/mediawiki/php-1.32.0-wmf.18/extensions/Wikibase/client/includes/LangLinkHandler.php(352): Wikibase\Client\LangLinkHandler->getEffectiveRepoLinks(Title, ParserOutput) #18 /srv/mediawiki/php-1.32.0-wmf.18/extensions/Wikibase/client/includes/Hooks/ParserOutputUpdateHookHandlers.php(97): Wikibase\Client\LangLinkHandler->addLinksFromRepository(Title, ParserOutput) #19 /srv/mediawiki/php-1.32.0-wmf.18/extensions/Wikibase/client/includes/Hooks/ParserOutputUpdateHookHandlers.php(65): Wikibase\Client\Hooks\ParserOutputUpdateHookHandlers->doContentAlterParserOutput(Title, ParserOutput) #20 /srv/mediawiki/php-1.32.0-wmf.18/includes/Hooks.php(174): Wikibase\Client\Hooks\ParserOutputUpdateHookHandlers::onContentAlterParserOutput(WikitextContent, Title, ParserOutput) #21 /srv/mediawiki/php-1.32.0-wmf.18/includes/Hooks.php(202): Hooks::callHook(string, array, array, NULL) #22 /srv/mediawiki/php-1.32.0-wmf.18/includes/content/AbstractContent.php(520): Hooks::run(string, array) #23 /srv/mediawiki/php-1.32.0-wmf.18/includes/poolcounter/PoolWorkArticleView.php(145): AbstractContent->getParserOutput(Title, integer, ParserOptions) #24 /srv/mediawiki/php-1.32.0-wmf.18/includes/poolcounter/PoolCounterWork.php(123): PoolWorkArticleView->doWork() #25 /srv/mediawiki/php-1.32.0-wmf.18/includes/page/Article.php(604): PoolCounterWork->execute() #26 /srv/mediawiki/php-1.32.0-wmf.18/includes/actions/ViewAction.php(68): Article->view() #27 /srv/mediawiki/php-1.32.
[Wikidata-bugs] [Maniphest] [Reassigned] T202032: Duplicate ar_rev_id values in several wikis
tstarling reassigned this task from tstarling to Anomie. TASK DETAILhttps://phabricator.wikimedia.org/T202032EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Anomie, tstarlingCc: gerritbot, Aklapper, daniel, aude, Addshore, Anomie, Abit, jcrespo, tstarling, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, PDrouin-WMF, Gq86, Baloch007, E1presidente, Ramsey-WMF, Cparle, Darkminds3113, Anooprao, SandraF_WMF, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, Tramullas, Acer, LawExplorer, Lewizho99, JJMC89, Maathavan, Agabi10, Susannaanas, Aschroet, Fjalapeno, Jane023, Wikidata-bugs, Base, matthiasmullie, Ricordisamoa, Lydia_Pintscher, Fabrice_Florin, Raymond, Steinsplitter, Mbch331, Ltrlg___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T183488: MCR schema migration stage 2: populate new fields
tstarling added a comment. enwiki is complete now, so only the T202032 wikis remain.TASK DETAILhttps://phabricator.wikimedia.org/T183488EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: tstarlingCc: jcrespo, greg, tstarling, Stashbot, Abit, gerritbot, Jdforrester-WMF, Anomie, Addshore, aude, Aklapper, daniel, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, PDrouin-WMF, Gq86, Baloch007, E1presidente, Ramsey-WMF, Cparle, Darkminds3113, Anooprao, SandraF_WMF, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, Tramullas, Acer, LawExplorer, Lewizho99, JJMC89, Maathavan, Agabi10, Susannaanas, Aschroet, Fjalapeno, Jane023, Wikidata-bugs, Base, matthiasmullie, Ricordisamoa, Lydia_Pintscher, Fabrice_Florin, Raymond, Steinsplitter, Mbch331, Ltrlg___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T183488: MCR schema migration stage 2: populate new fields
tstarling added a comment. Current status: everything is done except enwiki and the T202032 wikis. enwiki has about another 49 hours to run.TASK DETAILhttps://phabricator.wikimedia.org/T183488EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: tstarlingCc: jcrespo, greg, tstarling, Stashbot, Abit, gerritbot, Jdforrester-WMF, Anomie, Addshore, aude, Aklapper, daniel, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, PDrouin-WMF, Gq86, Baloch007, E1presidente, Ramsey-WMF, Cparle, Darkminds3113, Anooprao, SandraF_WMF, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, Tramullas, Acer, LawExplorer, Lewizho99, JJMC89, Maathavan, Agabi10, Susannaanas, Aschroet, Fjalapeno, Jane023, Wikidata-bugs, Base, matthiasmullie, Ricordisamoa, Lydia_Pintscher, Fabrice_Florin, Raymond, Steinsplitter, Mbch331, Ltrlg___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T202032: Duplicate ar_rev_id values in several wikis
tstarling created this task.tstarling triaged this task as "Normal" priority.tstarling added projects: Structured-Data-Commons, Multi-Content-Revisions (MCR Deployment), Core-Platform-Team (CPT-Q1-Jul-Sep-2018).Restricted Application added a subscriber: Aklapper.Restricted Application added a project: Wikidata. TASK DESCRIPTIONSome wikis have archive tables with duplicate ar_rev_id values. This causes duplicate key errors when running populateContentTables.php. Analysis populateArchiveRevId.php allocated rev_id values by inserting a dummy row into the revision table and then deleting it in the same transaction. It's evident from the MariaDB documentation that this is unsafe in MariaDB 10.1. In fact even ordinary article deletion is unsafe in MariaDB 10.1: if the latest revision is deleted, and then the master DB server is restarted, the autoincrement value will be reset to MAX(rev_id)+1 and so new revision creations will reuse the ID supposedly reserved by ar_rev_id. According to the MySQL documentation, the autoincrement value will be reset to MAX(...)+1 if a row is inserted or updated with a non-null value specified for the autoincrement column. It is unclear whether this is also true for MariaDB. The affected wikis are: aawikibooks, cawiki, gotwikibooks, kswikiquote, lvwikibooks, nostalgiawiki, wawikibooks and wikimania2005wiki. Taking aawikibooks as an example: The deletion log shows that 1749 pages in namespace 8 were deleted in 2007. Another 28 pages were also deleted in 2007. Then one was deleted in 2008. In 2015, 5 pages were deleted, with 9 revisions.. This is a closed, read-only wiki which has not been edited since 2015. ar_rev_id was apparently introduced in 2005, so none of these archive rows should have had ar_rev_id=NULL, and so none should have been affected by populateContentTables.php. But I can't see how it could have been caused by the original deletion in October 2007, since there are conflicting ar_rev_id values for revisions that would have been in the revision table at the same time. A list of affected archive rows in aawikibooks: P7461 aawikibooks ar_rev_id conflicts Note that ar_id was only introduced in 2012, it's not exactly monotonic with deletion time. Some deletion times: wikiadmin@10.64.16.191(aawikibooks)> select ar_id,log_timestamp from logging,archive where log_namespace=ar_namespace and log_title=ar_title and ar_id in (29,985,987,1018,1849,92,3204,6569) order by log_timestamp; +---++ | ar_id | log_timestamp | +---++ |29 | 20070108212726 | |29 | 20070108212726 | |92 | 20070108212729 | |92 | 20070108212729 | | 985 | 20070108212804 | | 985 | 20070108212804 | | 987 | 20070108212804 | | 987 | 20070108212804 | | 1018 | 20070108212805 | | 1018 | 20070108212805 | | 1849 | 20070108212826 | | 1849 | 20070108212826 | | 6569 | 20070918192042 | | 6569 | 20070918192042 | | 3204 | 20070918192049 | | 3204 | 20070918192049 | | 6569 | 20080328185334 | +---++ In summary, I don't know what happened but it's obviously broken. The MCR write-both mode, with its unique index on slot_revision_id, should at least prevent conflicting rows from being inserted, although this potentially comes at the cost of throwing an exception on every edit until someone manually advances the autoincrement value for rev_id is advanced beyond MAX(ar_rev_id). That is to say, if the most recent revision is deleted, and then a master switch is done, all edits would fail until manual action is taken. Fixing it In the long term, we will have to stop using ar_rev_id, since evidently we made incorrect assumptions about how DBMSs work. The whole concept of ar_rev_id appears to be invalid. A quick hack would be to permanently insert a row into the revision table of the affected wikis, with a rev_id specified so as to make room for the extra ar_rev_id values. This wouldn't fix the master switch issue. When inserting a row into revision, we could do SELECT MAX(ar_rev_id) FROM archive. If the rev_id returned when inserting is less than MAX(ar_rev_id), then we could update the rev_id in the newly-inserted row to some larger value.TASK DETAILhttps://phabricator.wikimedia.org/T202032EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: tstarlingCc: Aklapper, daniel, aude, Addshore, Anomie, Abit, jcrespo, tstarling, Lahi, PDrouin-WMF, Gq86, E1presidente, Ramsey-WMF, Cparle, Anooprao, SandraF_WMF, GoranSMilovanovic, QZanden, Tramullas, Acer, LawExplorer, JJMC89, Agabi10, Susannaanas, Aschroet, Fjalapeno, Jane023, Wikidata-bugs, Base, matthiasmullie, Ricordisamoa, Lydia_Pintscher, Fabrice_Florin, Raymond, Steinsplitter, Mbch331, Ltrlg___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T183488: MCR schema migration stage 2: populate new fields
tstarling added a comment. So how do we end up trying to insert a row for revision 3003 twice? max(rev_id) on this wiki is 3002, so the ar_rev_id certainly came from populateArchiveRevId.php, which allocated ar_rev_id values by inserting dummy rows into revision and deleting them in the same transaction. It may be that MySQL has some method to reallocate autoincremented IDs in this case which we didn't know about.TASK DETAILhttps://phabricator.wikimedia.org/T183488EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: tstarlingCc: jcrespo, greg, tstarling, Stashbot, Abit, gerritbot, Jdforrester-WMF, Anomie, Addshore, aude, Aklapper, daniel, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, PDrouin-WMF, Gq86, Baloch007, E1presidente, Ramsey-WMF, Cparle, Darkminds3113, Anooprao, SandraF_WMF, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, Tramullas, Acer, LawExplorer, Lewizho99, JJMC89, Maathavan, Agabi10, Susannaanas, Aschroet, Fjalapeno, Jane023, Wikidata-bugs, Base, matthiasmullie, Ricordisamoa, Lydia_Pintscher, Fabrice_Florin, Raymond, Steinsplitter, Mbch331, Ltrlg___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T183488: MCR schema migration stage 2: populate new fields
tstarling added a comment. You can see the full logs at mwmaint1001:/var/log/mediawiki/populateContentTables/ . On both aawikibooks and gotwikibooks, the error occurred on the second batch of the archive table, starting at ar_rev_id 2001. In both cases it was also the last batch, with the maximum ar_rev_id being 3275 and 3175 respectively.TASK DETAILhttps://phabricator.wikimedia.org/T183488EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: tstarlingCc: jcrespo, greg, tstarling, Stashbot, Abit, gerritbot, Jdforrester-WMF, Anomie, Addshore, aude, Aklapper, daniel, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, PDrouin-WMF, Gq86, Baloch007, E1presidente, Ramsey-WMF, Cparle, Darkminds3113, Anooprao, SandraF_WMF, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, Tramullas, Acer, LawExplorer, Lewizho99, JJMC89, Maathavan, Agabi10, Susannaanas, Aschroet, Fjalapeno, Jane023, Wikidata-bugs, Base, matthiasmullie, Ricordisamoa, Lydia_Pintscher, Fabrice_Florin, Raymond, Steinsplitter, Mbch331, Ltrlg___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T183488: MCR schema migration stage 2: populate new fields
tstarling added a comment. Log summary: aawikibooks failed with "Error: 1062 Duplicate entry '3003-1' for key 'PRIMARY' (10.64.0.205)" cawiki failed with "Replication wait failed: Server shutdown in progress" and will need to be restarted. gotwikibooks also failed with a duplicate key error s5 (dewiki) is complete s2 was killed So 4 concurrent processes are currently running: s1, s3, s6 and s7.TASK DETAILhttps://phabricator.wikimedia.org/T183488EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: tstarlingCc: jcrespo, greg, tstarling, Stashbot, Abit, gerritbot, Jdforrester-WMF, Anomie, Addshore, aude, Aklapper, daniel, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, PDrouin-WMF, Gq86, Baloch007, E1presidente, Ramsey-WMF, Cparle, Darkminds3113, Anooprao, SandraF_WMF, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, Tramullas, Acer, LawExplorer, Lewizho99, JJMC89, Maathavan, Agabi10, Susannaanas, Aschroet, Fjalapeno, Jane023, Wikidata-bugs, Base, matthiasmullie, Ricordisamoa, Lydia_Pintscher, Fabrice_Florin, Raymond, Steinsplitter, Mbch331, Ltrlg___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T183488: MCR schema migration stage 2: populate new fields
tstarling added a comment. In T183488#4499288, @jcrespo wrote: @tstarling Please stop writes going to *s2* unless they have already finished Done. s2 was up to itwiki rev_id 3012040. enwiki should take about another 6 days at the current rate.TASK DETAILhttps://phabricator.wikimedia.org/T183488EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: tstarlingCc: jcrespo, greg, tstarling, Stashbot, Abit, gerritbot, Jdforrester-WMF, Anomie, Addshore, aude, Aklapper, daniel, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, PDrouin-WMF, Gq86, Baloch007, E1presidente, Ramsey-WMF, Cparle, Darkminds3113, Anooprao, SandraF_WMF, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, Tramullas, Acer, LawExplorer, Lewizho99, JJMC89, Maathavan, Agabi10, Susannaanas, Aschroet, Fjalapeno, Jane023, Wikidata-bugs, Base, matthiasmullie, Ricordisamoa, Lydia_Pintscher, Fabrice_Florin, Raymond, Steinsplitter, Mbch331, Ltrlg___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Closed] T198049: Investigate possible outage on wikidata on 25th June - 04:13AM UTC - 05:27AM UTC
tstarling closed this task as "Resolved".tstarling added a project: Core-Platform-Team (CPT-Q1-Jul-Sep-2018).tstarling claimed this task. TASK DETAILhttps://phabricator.wikimedia.org/T198049EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: tstarlingCc: tstarling, jcrespo, hoo, Lydia_Pintscher, daniel, Ladsgroup, Marostegui, AndyTan, Davinaclare77, Qtn1293, Lahi, Gq86, GoranSMilovanovic, Th3d3v1ls, Hfbn0, QZanden, LawExplorer, Zppix, Wong128hk, Fjalapeno, Wikidata-bugs, aude, faidon, Mbch331, Jay8g, fgiunchedi___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T198049: Investigate possible outage on wikidata on 25th June - 04:13AM UTC - 05:27AM UTC
tstarling added a comment. db1071, the master, had no writes It actually had a factor of 10 fewer writes, not zero writes. I'm pretty sure there was no outage. I had a closer look at the exceptions. Most of them came from jobs. There's a sizeable minority that came from appservers. Sampling a few shows they are from DeferredUpdates. For example LinksUpdate and GlobalUsage write batches of rows in a loop with commitAndWaitForReplication(). This means updates are being skipped. Unlike a job there is no possibility of a retry. This was a change made in 2016 as part of T95501. I'll file a bug for this. Otherwise, I think I'm done with this incident.TASK DETAILhttps://phabricator.wikimedia.org/T198049EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: tstarlingCc: tstarling, jcrespo, hoo, Lydia_Pintscher, daniel, Ladsgroup, Marostegui, AndyTan, Davinaclare77, Qtn1293, Lahi, Gq86, GoranSMilovanovic, Th3d3v1ls, Hfbn0, QZanden, LawExplorer, Zppix, Wong128hk, Wikidata-bugs, aude, faidon, Mbch331, Jay8g, fgiunchedi___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T198049: Investigate possible outage on wikidata on 25th June - 04:13AM UTC - 05:27AM UTC
tstarling added a comment. The drop may have been caused by the API maxlag parameter. Wikidata:Bots recommends using a maxlag parameter, and some client libraries set maxlag=5 by default. The point of this feature is to make bots pause during replication lag, to prioritise human users and avoid worsening the situation. The relevant logs from this period have been deleted, so some guesswork is needed. I looked at the edits before the issue, between 3:50 and 4:00, and during the issue, between 4:20 and 4:30. In the earlier period, 7 out of the top 10 editors had "bot" in their names. Out of the remaining 3, 2 were using QuickStatements, a tool labs tool which edits at a high rate via OAuth. These 9 fully automated editors made 2727 edits in the earlier period, and 3 edits during the event. The last of the top 10, Ghuron, made 240 edits in the earlier period and 48 during the event. The edits were repetitive, and similar in character across the two time periods. If you exclude the top 10 editors from the earlier period from the analysis, the remaining edit rate only dropped from 194 to 115. The total number of unique users dropped from 53 to 38. Maybe we should add some maxlag metrics to statsd.TASK DETAILhttps://phabricator.wikimedia.org/T198049EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: tstarlingCc: tstarling, jcrespo, hoo, Lydia_Pintscher, daniel, Ladsgroup, Marostegui, AndyTan, Davinaclare77, Qtn1293, Lahi, Gq86, GoranSMilovanovic, Th3d3v1ls, Hfbn0, QZanden, LawExplorer, Zppix, Wong128hk, Wikidata-bugs, aude, faidon, Mbch331, Jay8g, fgiunchedi___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T198049: Investigate possible outage on wikidata on 25th June - 04:13AM UTC - 05:27AM UTC
tstarling added a comment.
In T198049#4310346, @jcrespo wrote:
51,715 exceptions with:
[{exception_id}] {exception_url} Wikimedia\Rdbms\DBReplicationWaitError from line 426 of /srv/mediawiki/php-1.32.0-wmf.8/includes/libs/rdbms/lbfactory/LBFactory.php: Could not wait for replica DBs to catch up to db1071
These exceptions are from maintenance scripts. Prior to December 2015 the policy was for maintenance scripts to just wait forever in the case of replication lag, but since fedfee628c377eeea0453ed82af02b6878bd525b it throws an exception after a hard-coded 60 seconds. According to the commit message this "makes failure more explicit". I suppose it also allows a job runner to reconfigure itself if a slave is dropped.
The reason for the prior policy was because at the time, lag was very common, scripts were not always restartable.
Unfortunately it does not help to isolate the problem since exception spam is now the inevitable and harmless consequence of >60s lag.TASK DETAILhttps://phabricator.wikimedia.org/T198049EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: tstarlingCc: tstarling, jcrespo, hoo, Lydia_Pintscher, daniel, Ladsgroup, Marostegui, AndyTan, Davinaclare77, Qtn1293, Lahi, Gq86, GoranSMilovanovic, Th3d3v1ls, Hfbn0, QZanden, LawExplorer, Zppix, Wong128hk, Wikidata-bugs, aude, faidon, Mbch331, Jay8g, fgiunchedi___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T183488: MCR schema migration stage 2: populate new fields
tstarling added a comment. @greg The WN31 things are done now, only 1081 seconds for mediawikiwiki and 9252 seconds for metawiki. For metawiki the rate was about the same as anomie got for testwiki, 2000 rows per second for the revision table and 600 rows per second for the archive table. At that rate, we can expect wikidatawiki to take about 91 hours and commonswiki to take about 48 hours. We can run them concurrently since they are on different DB clusters, and that way maybe get them done by the end of the week.TASK DETAILhttps://phabricator.wikimedia.org/T183488EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Anomie, tstarlingCc: greg, tstarling, Stashbot, Abit, gerritbot, Jdforrester-WMF, Anomie, Addshore, aude, Aklapper, daniel, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, PDrouin-WMF, Gq86, Baloch007, E1presidente, Ramsey-WMF, Cparle, Darkminds3113, Anooprao, SandraF_WMF, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, Tramullas, Acer, LawExplorer, Lewizho99, JJMC89, Maathavan, Agabi10, Susannaanas, Aschroet, Jane023, Wikidata-bugs, Base, matthiasmullie, Ricordisamoa, Lydia_Pintscher, Fabrice_Florin, Raymond, Steinsplitter, Mbch331, Ltrlg___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Unblock] T183488: MCR schema migration stage 2: populate new fields
tstarling closed subtask T197816: Enable MCR migration stage "write both, read old" on live systems as "Resolved". TASK DETAILhttps://phabricator.wikimedia.org/T183488EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Anomie, tstarlingCc: greg, tstarling, Stashbot, Abit, gerritbot, Jdforrester-WMF, Anomie, Addshore, aude, Aklapper, daniel, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, PDrouin-WMF, Gq86, Baloch007, E1presidente, Ramsey-WMF, Cparle, Darkminds3113, Anooprao, SandraF_WMF, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, Tramullas, Acer, LawExplorer, Lewizho99, JJMC89, Maathavan, Agabi10, Susannaanas, Aschroet, Jane023, Wikidata-bugs, Base, matthiasmullie, Ricordisamoa, Lydia_Pintscher, Fabrice_Florin, Raymond, Steinsplitter, Mbch331, Ltrlg___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Closed] T197816: Enable MCR migration stage "write both, read old" on live systems
tstarling closed this task as "Resolved".tstarling claimed this task. TASK DETAILhttps://phabricator.wikimedia.org/T197816EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: tstarlingCc: Aklapper, gerritbot, aude, Addshore, Anomie, Jdforrester-WMF, Abit, daniel, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, PDrouin-WMF, Gq86, Baloch007, E1presidente, Ramsey-WMF, Cparle, Darkminds3113, Anooprao, SandraF_WMF, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, Tramullas, Acer, LawExplorer, Lewizho99, JJMC89, Maathavan, Agabi10, Susannaanas, Aschroet, Jane023, Wikidata-bugs, Base, matthiasmullie, Ricordisamoa, Lydia_Pintscher, Fabrice_Florin, Raymond, Steinsplitter, Mbch331, Ltrlg___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Unblock] T194750: Deploy Structured Data on Commons baseline
tstarling closed subtask T197816: Enable MCR migration stage "write both, read old" on live systems as "Resolved". TASK DETAILhttps://phabricator.wikimedia.org/T194750EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: tstarlingCc: Cparle, Aklapper, Abit, Ramsey-WMF, daniel, Lahi, PDrouin-WMF, Gq86, E1presidente, Anooprao, SandraF_WMF, GoranSMilovanovic, QZanden, Tramullas, Acer, V4switch, LawExplorer, JJMC89, Agabi10, Susannaanas, Wong128hk, Aschroet, Jane023, Wikidata-bugs, Base, matthiasmullie, aude, Ricordisamoa, Lydia_Pintscher, Fabrice_Florin, Raymond, Steinsplitter, Matanya, Mbch331, Ltrlg___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T183488: MCR schema migration stage 2: populate new fields
tstarling added a comment. test2wiki and testwikidatawiki are complete.TASK DETAILhttps://phabricator.wikimedia.org/T183488EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Anomie, tstarlingCc: tstarling, Stashbot, Abit, gerritbot, Jdforrester-WMF, Anomie, Addshore, aude, Aklapper, daniel, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, PDrouin-WMF, Gq86, Baloch007, E1presidente, Ramsey-WMF, Cparle, Darkminds3113, Anooprao, SandraF_WMF, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, Tramullas, Acer, LawExplorer, Lewizho99, JJMC89, Maathavan, Agabi10, Susannaanas, Aschroet, Jane023, Wikidata-bugs, Base, matthiasmullie, Ricordisamoa, Lydia_Pintscher, Fabrice_Florin, Raymond, Steinsplitter, Mbch331, Ltrlg___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T183488: MCR schema migration stage 2: populate new fields
tstarling added a comment. Daniel proposed the following schedule: Today: test2wiki, testwikidatawiki This week (WN31): mediawikiwiki, metawiki Next week (WN32): wikidatawiki, commonswiki Week after (WN33): everything I'm going to start on this now.TASK DETAILhttps://phabricator.wikimedia.org/T183488EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Anomie, tstarlingCc: tstarling, Stashbot, Abit, gerritbot, Jdforrester-WMF, Anomie, Addshore, aude, Aklapper, daniel, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, PDrouin-WMF, Gq86, Baloch007, E1presidente, Ramsey-WMF, Cparle, Darkminds3113, Anooprao, SandraF_WMF, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, Tramullas, Acer, LawExplorer, Lewizho99, JJMC89, Maathavan, Agabi10, Susannaanas, Aschroet, Jane023, Wikidata-bugs, Base, matthiasmullie, Ricordisamoa, Lydia_Pintscher, Fabrice_Florin, Raymond, Steinsplitter, Mbch331, Ltrlg___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T182348: dcatap.rdf in dumps contains invalid data
tstarling added a comment. In T182348#3883001, @ArielGlenn wrote: It should be back on php5 now, I went through all the misc dumps crons, made sure they all use the config setting for php in the dumps config, and that is php5. See https://gerrit.wikimedia.org/r/#/c/400692/ Why would you revert this without even talking to me? Did you even check if DCAT.php was updated on the server after my change was merged?TASK DETAILhttps://phabricator.wikimedia.org/T182348EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hoo, tstarlingCc: tstarling, hoo, ArielGlenn, Lokal_Profil, Aklapper, Smalyshev, Lahi, Gq86, GoranSMilovanovic, Lunewa, QZanden, LawExplorer, gnosygnu, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T145819: Jobs invoking SiteConfiguration::getConfig cause HHVM to fail updating the bytecode cache due to being filesize limited to 512MBytes
tstarling removed a subtask: T161598: Monitor HHVM bytecode cache depletion on mediawiki app servers. TASK DETAILhttps://phabricator.wikimedia.org/T145819EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: tstarlingCc: tstarling, thcipriani, Anomie, aaron, MZMcBride, Tobi_WMDE_SW, FastLizard4, JJMC89, zeljkofilipin, Lydia_Pintscher, daniel, aude, Addshore, Aklapper, greg, Legoktm, demon, gerritbot, Stashbot, hashar, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, Lewizho99, Maathavan, Liudvikas, Luke081515, Wikidata-bugs, ArielGlenn, He7d3r, Mbch331, Jay8g, Krenair, fgiunchedi, jeremyb, mmodell___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Assigned] T174032: Make relevant API modules aware of MCR
tstarling assigned this task to Anomie. TASK DETAILhttps://phabricator.wikimedia.org/T174032EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Anomie, tstarlingCc: Aklapper, daniel, Lahi, PDrouin-WMF, Gq86, E1presidente, Ramsey-WMF, Cparle, SandraF_WMF, GoranSMilovanovic, QZanden, Tramullas, Acer, LawExplorer, Susannaanas, Aschroet, Jane023, Wikidata-bugs, PKM, Base, matthiasmullie, aude, Ricordisamoa, Lydia_Pintscher, Fabrice_Florin, Raymond, Anomie, Steinsplitter, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Assigned] T183489: MCR schema migration stage 1: Fix Legacy Archive Rows
tstarling assigned this task to Anomie. TASK DETAILhttps://phabricator.wikimedia.org/T183489EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Anomie, tstarlingCc: Jdforrester-WMF, Aklapper, aude, Addshore, Anomie, daniel, Lahi, PDrouin-WMF, Gq86, E1presidente, Ramsey-WMF, Cparle, SandraF_WMF, GoranSMilovanovic, QZanden, Tramullas, Acer, LawExplorer, Susannaanas, Aschroet, Jane023, Wikidata-bugs, PKM, Base, matthiasmullie, Ricordisamoa, Lydia_Pintscher, Fabrice_Florin, Raymond, Steinsplitter, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Assigned] T182678: [MCR] Script for populating empty ar_rev_id fields
tstarling assigned this task to Anomie. TASK DETAILhttps://phabricator.wikimedia.org/T182678EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Anomie, tstarlingCc: gerritbot, Anomie, aude, Aklapper, Adrian1985, Cpaulf30, Lahi, PDrouin-WMF, Gq86, Baloch007, E1presidente, Ramsey-WMF, Cparle, Darkminds3113, SandraF_WMF, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, Tramullas, Acer, LawExplorer, Lewizho99, Maathavan, Susannaanas, Aschroet, Jane023, Wikidata-bugs, PKM, Base, matthiasmullie, Ricordisamoa, Lydia_Pintscher, Fabrice_Florin, Raymond, Steinsplitter, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T174024: Implement MCR revision retrieval interface
tstarling added subscribers: Addshore, tstarling.tstarling added a comment. This is on our workboard and Q3 goal list but https://wikifarm.wmflabs.org/mcr/index.php/Main_Page has it assigned to Adam, I assume that is @Addshore. Is it OK to assign this task?TASK DETAILhttps://phabricator.wikimedia.org/T174024EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: tstarlingCc: tstarling, Addshore, gerritbot, Aklapper, daniel, Lahi, PDrouin-WMF, Gq86, E1presidente, Ramsey-WMF, Cparle, SandraF_WMF, GoranSMilovanovic, QZanden, Tramullas, Acer, LawExplorer, Susannaanas, Aschroet, Jane023, Wikidata-bugs, PKM, Base, matthiasmullie, aude, Ricordisamoa, Lydia_Pintscher, Fabrice_Florin, Raymond, Anomie, Steinsplitter, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Closed] T145819: Jobs invoking SiteConfiguration::getConfig cause HHVM to fail updating the bytecode cache due to being filesize limited to 512MBytes
tstarling closed this task as "Resolved".tstarling claimed this task.tstarling added a comment. The fix is merged, and searching logstash for SiteConfiguration shows no further errors of this type.TASK DETAILhttps://phabricator.wikimedia.org/T145819EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: tstarlingCc: tstarling, thcipriani, Anomie, aaron, MZMcBride, Tobi_WMDE_SW, FastLizard4, JJMC89, zeljkofilipin, Lydia_Pintscher, daniel, aude, Addshore, Aklapper, greg, Legoktm, demon, gerritbot, Stashbot, hashar, Lahi, Gq86, Baloch007, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, Lewizho99, Maathavan, Liudvikas, Luke081515, Wikidata-bugs, ArielGlenn, He7d3r, Mbch331, Jay8g, Krenair, fgiunchedi, jeremyb, mmodell___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Unblock] T170281: Raise PHP version requirement of Wikibase (and its related extensions) to 5.6
tstarling closed subtask T178538: Bump PHP requirement to 5.6 in 1.31 as "Declined". TASK DETAILhttps://phabricator.wikimedia.org/T170281EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: tstarlingCc: Paladox, Ricordisamoa, PokestarFan, thiemowmde, Reedy, Lucas_Werkmeister_WMDE, aude, hoo, ArielGlenn, daniel, Lydia_Pintscher, Jonas, Aleksey_WMDE, WMDE-leszek, Aklapper, Lahi, Gq86, GoranSMilovanovic, QZanden, Wikidata-bugs, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T176312: Don’t check format constraint via SPARQL (safely evaluating user-provided regular expressions)
tstarling added a comment. If you just want an approximately PCRE-like syntax, you could just translate the regex to a Lua pattern. Scribunto has equivalent code going in the other direction, in Scribunto_LuaUstringLibrary::patternToRegex(), which you could look at for ideas. Obviously you would be implementing a subset of PCRE features. The nice thing about Lua patterns is that I've reviewed the code and patched out the DoS vulnerabilities. I don't think there are many other regex libraries which have been verified as safe for arbitrary user input, with limited time and memory.TASK DETAILhttps://phabricator.wikimedia.org/T176312EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: tstarlingCc: tstarling, daniel, GWicke, Joe, Lucas_Werkmeister_WMDE, Krinkle, Aklapper, GoranSMilovanovic, QZanden, Agabi10, Izno, SBisson, Wikidata-bugs, aude, jayvdb, fbstj, RobLa-WMF, santhosh, Jdforrester-WMF, Mbch331, Rxy, Jay8g, Ltrlg, bd808, Legoktm___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T44689: AddRowIDs.sql fails on sqlite
tstarling removed a parent task: T22257: SQLite support (tracking). TASK DETAILhttps://phabricator.wikimedia.org/T44689EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: tstarlingCc: wikibugs-l-list, Wikidata-bugs, Denny, Lydia_Pintscher, daniel, Unknown Object (MLST), GoranSMilovanovic, QZanden, Izno, aude, waldyrious, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T44688: AddTermSearchKey.sql fails on sqlite
tstarling removed a parent task: T22257: SQLite support (tracking). TASK DETAILhttps://phabricator.wikimedia.org/T44688EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: tstarlingCc: wikibugs-l-list, Wikidata-bugs, Abraham, Denny, aude, daniel, Unknown Object (MLST), GoranSMilovanovic, QZanden, Izno, waldyrious, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T44689: AddRowIDs.sql fails on sqlite
tstarling added a project: SQLite.Herald added a project: Wikidata. TASK DETAILhttps://phabricator.wikimedia.org/T44689EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: tstarlingCc: wikibugs-l-list, Wikidata-bugs, Denny, Lydia_Pintscher, daniel, Unknown Object (MLST), GoranSMilovanovic, QZanden, Izno, aude, waldyrious, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T44688: AddTermSearchKey.sql fails on sqlite
tstarling added a project: SQLite.Herald added a project: Wikidata. TASK DETAILhttps://phabricator.wikimedia.org/T44688EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: tstarlingCc: wikibugs-l-list, Wikidata-bugs, Abraham, Denny, aude, daniel, Unknown Object (MLST), GoranSMilovanovic, QZanden, Izno, waldyrious, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T107595: [RFC] Multi-Content Revisions
tstarling added a project: MediaWiki-Platform-Team. TASK DETAILhttps://phabricator.wikimedia.org/T107595EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: brion, tstarlingCc: SBisson, Izno, Pppery, Alsee, Florian, Liuxinyu970226, WMDE-leszek, Mholloway, Scott_WUaS, Niharika, MGChecker, LikeLifer, Elitre, Glaisher, JJMC89, RobLa-WMF, Yurik, ArielGlenn, APerson, TomT0m, Krenair, intracer, Tgr, Tobi_WMDE_SW, Addshore, Lydia_Pintscher, cscott, PleaseStand, awight, Ricordisamoa, GWicke, waldyrious, Legoktm, Aklapper, Jdforrester-WMF, Ltrlg, brion, Spage, MZMcBride, daniel, QZanden, D3r1ck01, Luke081515, Wikidata-bugs, aude, jayvdb, fbstj, santhosh, Mbch331, Jay8g, bd808___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Project Column] T114443: EventBus MVP
tstarling moved this task to Under discussion on the MediaWiki-RfCs workboard. TASK DETAIL https://phabricator.wikimedia.org/T114443 WORKBOARD https://phabricator.wikimedia.org/project/board/52/ EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Ottomata, tstarling Cc: mark, MZMcBride, Krinkle, EBernhardson, bd808, Joe, dr0ptp4kt, madhuvishy, Nuria, ori, faidon, aaron, GWicke, mobrovac, Eevans, Ottomata, Matanya, Aklapper, JGirault, JAllemandou, jkroll, Smalyshev, Hardikj, Wikidata-bugs, Jdouglas, RobH, aude, Deskana, Manybubbles, daniel, JanZerebecki, RobLa-WMF, Jay8g, Ltrlg, fgiunchedi, Dzahn, jeremyb, Legoktm, chasemp, Krenair ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T107941: Pagebanner extension and api=parse and api=expandtemplates endpoinds
tstarling added a subscriber: tstarling. tstarling added a comment. The API output is correct. That parser function returns no text, and sets a property with name wpb-banner-options. The extension uses a BeforePageDisplay hook to modify the HTML depending on the wpb-banner-options property. The action=expandtemplates module does not, and should not, call the BeforePageDisplay hook. Parsoid fetches the ParserOutput properties but has no special handling for wpb-banner-options. Presumably it should be handled in a similar way to DISPLAYTITLE and DEFAULTSORT. TASK DETAIL https://phabricator.wikimedia.org/T107941 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: tstarling Cc: tstarling, ssastry, Aklapper, Jdlrobson, Jrf, Husun1297, Wikidata-bugs, Ryasmeen, Etonkovidova, aude, Swainr, Lydia_Pintscher, Arlolra, Jdforrester-WMF, Malyacko, P.Copp ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Retitled] T107941: Parsoid has no special handling for the properties set by WikidataPageBanner
tstarling changed the title from Pagebanner extension and api=parse and api=expandtemplates endpoinds to Parsoid has no special handling for the properties set by WikidataPageBanner. TASK DETAIL https://phabricator.wikimedia.org/T107941 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: tstarling Cc: tstarling, ssastry, Aklapper, Jdlrobson, Jrf, Husun1297, Wikidata-bugs, Ryasmeen, Etonkovidova, aude, Swainr, Lydia_Pintscher, Arlolra, Jdforrester-WMF, Malyacko, P.Copp ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T43103: initialization of the Language object is very heavy
tstarling added subscribers: bzimport, tstarling. tstarling added a comment. In https://phabricator.wikimedia.org/T43103#442763, @bzimport wrote: **bugzilla.wikimedia** wrote: (In reply to comment #8) ... We really need to be able to get Language objects without loading all the messages. This could be done by lazy initialization - only loading the messages when they are first used. That's what we do already, since MW 1.16, except for the preload key, which is a small set of messages that are preloaded for optimal parser cache hit performance. Are you saying that preloading should be deferred? Or are you talking about something else, like MessageCache? TASK DETAIL https://phabricator.wikimedia.org/T43103 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: tstarling Cc: tstarling, bzimport, Wikidata-bugs, Amire80, siebrand, jeblad, SPQRobin, jayvdb, Denny, DanielFriesen, Nikerabbit, daniel, GWicke, Gryllida, Shizhao, Arrbee, KartikMistry, wikibugs-l ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
