[Wikidata-bugs] [Maniphest] T359149: Wikibase apitests broken in CI: Unsupported Content-Type: application/json-patch+json
daniel moved this task from Incoming (Needs Triage) to Done on the MW-Interfaces-Team board. daniel added a comment. I think this should be fixed now, can you confirm? TASK DETAIL https://phabricator.wikimedia.org/T359149 WORKBOARD https://phabricator.wikimedia.org/project/board/6931/ EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Ifrahkhanyaree_WMDE, Jdforrester-WMF, daniel, Lucas_Werkmeister_WMDE, Aklapper, Jakob_WMDE, Danny_Benjafield_WMDE, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, ItamarWMDE, Akuckartz, apaskulin, Nandana, Lahi, Gq86, Xinbenlv, GoranSMilovanovic, QZanden, KimKelting, 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] T359149: Wikibase apitests broken in CI: Unsupported Content-Type: application/json-patch+json
daniel added a project: MW-Interfaces-Team. TASK DETAIL https://phabricator.wikimedia.org/T359149 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Ifrahkhanyaree_WMDE, Jdforrester-WMF, daniel, Lucas_Werkmeister_WMDE, Aklapper, Jakob_WMDE, Danny_Benjafield_WMDE, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, ItamarWMDE, Akuckartz, apaskulin, Nandana, Lahi, Gq86, Xinbenlv, GoranSMilovanovic, QZanden, KimKelting, 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] T353199: prop=description does not respect language variants properly
daniel added a project: MW-Interfaces-Team. TASK DETAIL https://phabricator.wikimedia.org/T353199 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: tstarling, Ericliu1912, Winston_Sung, JTannerWMF, ABorbaWMF, matmarex, Aklapper, Tgr, Stang, cooltey, Danny_Benjafield_WMDE, Astuthiodit_1, Atieno, karapayneWMDE, Invadibot, DAbad, maantietaja, Confetti68, ItamarWMDE, DAlangi_WMF, Akuckartz, Nandana, lucamauri, Lahi, Gq86, Sharvaniharan, scblr, GoranSMilovanovic, QZanden, KimKelting, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Dbrant, 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] T359149: Wikibase apitests broken in CI: Unsupported Content-Type: application/json-patch+json
daniel added a comment. Working on a fix TASK DETAIL https://phabricator.wikimedia.org/T359149 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: daniel, Lucas_Werkmeister_WMDE, Aklapper, Jakob_WMDE, Danny_Benjafield_WMDE, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, ItamarWMDE, Akuckartz, apaskulin, Nandana, Lahi, Gq86, Xinbenlv, GoranSMilovanovic, QZanden, KimKelting, 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] T333966: message keys shown on beta and group0 wikis (test Wikidata, etc.)
daniel added a comment. In T333966#8758611 <https://phabricator.wikimedia.org/T333966#8758611>, @Ladsgroup wrote: > Not yet (that's why I didn't merge the revert on master), It should be easy to reproduce though, messages from extensions are not being added to the file. Does that happen in your localhost? I do see message files from extensions when I run the script locally, yes... TASK DETAIL https://phabricator.wikimedia.org/T333966 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Ladsgroup, daniel Cc: daniel, Etonkovidova, AlexisJazz, Urbanecm_WMF, Ladsgroup, Ammarpad, hashar, TheresNoTime, Jdforrester-WMF, Michael, Lucas_Werkmeister_WMDE, Aklapper, Lydia_Pintscher, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, ItamarWMDE, 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] T333966: message keys shown on beta and group0 wikis (test Wikidata, etc.)
daniel added a comment. In T333966#8755748 <https://phabricator.wikimedia.org/T333966#8755748>, @Ladsgroup wrote: > Okay, it fixed it in group0 so it should unblock the train but I haven't merged the path on master (force merging on master is even worse than force merging on a release branch), and I hope to find a solution instead of revert. Maybe @daniel can look into it? Did you identify what the actual issue is? or how to reproduce it locally? TASK DETAIL https://phabricator.wikimedia.org/T333966 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Ladsgroup, daniel Cc: daniel, Etonkovidova, AlexisJazz, Urbanecm_WMF, Ladsgroup, Ammarpad, hashar, TheresNoTime, Jdforrester-WMF, Michael, Lucas_Werkmeister_WMDE, Aklapper, Lydia_Pintscher, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, ItamarWMDE, 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] T196087: Refactored implementation of MCR page update interface
daniel closed subtask T195069: Factor PageStore and PageRecord out of WikiPage as "Resolved". TASK DETAIL https://phabricator.wikimedia.org/T196087 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Tgr, gerritbot, Aklapper, daniel, CCicalese_WMF, Astuthiodit_1, BeautifulBold, Suran38, karapayneWMDE, Invadibot, maantietaja, Naike, Peteosx1x, NavinRizwi, ItamarWMDE, Akuckartz, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, JJMC89, _jensen, rosalieper, Agabi10, Scott_WUaS, Wikidata-bugs, aude, Dinoguy1000, Jdforrester-WMF, Mbch331, 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] T174022: Implement multi-content revisions
daniel updated the task description. TASK DETAIL https://phabricator.wikimedia.org/T174022 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Magol, Lokal_Profil, AfroThundr3007730, Agabi10, Liuxinyu970226, TomT0m, Smalyshev, -jem-, Aklapper, daniel, Astuthiodit_1, BeautifulBold, Suran38, karapayneWMDE, toberto, Invadibot, GFontenelle_WMF, maantietaja, FRomeo_WMF, Naike, Peteosx1x, NavinRizwi, CBogen, ItamarWMDE, Nintendofan885, Akuckartz, eprodromou, DannyS712, Nandana, JKSTNK, Lahi, Gq86, E1presidente, Ramsey-WMF, Cparle, SandraF_WMF, GoranSMilovanovic, QZanden, Tramullas, Acer, LawExplorer, Salgo60, JJMC89, Silverfish, _jensen, rosalieper, Scott_WUaS, Susannaanas, Jane023, Wikidata-bugs, Base, matthiasmullie, aude, Dinoguy1000, Ricordisamoa, Wesalius, Lydia_Pintscher, Raymond, Jdforrester-WMF, Steinsplitter, Mbch331, 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] T138208: Connections to all db servers for wikidata as wikiadmin from snapshot, terbium
daniel added a comment. In T138208#7727286 <https://phabricator.wikimedia.org/T138208#7727286>, @Ladsgroup wrote: > At least it can avoid connecting to non-dump hosts. I thought we did that... maybe @ArielGlenn has an idea. TASK DETAIL https://phabricator.wikimedia.org/T138208 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: LSobanski, Ladsgroup, Marostegui, Addshore, Lydia_Pintscher, daniel, hoo, ArielGlenn, jcrespo, Zppix, karapayneWMDE, Invadibot, maantietaja, jannee_e, Akuckartz, holger.knust, Nandana, Lahi, Gq86, GoranSMilovanovic, Lunewa, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, gnosygnu, 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] T138208: Connections to all db servers for wikidata as wikiadmin from snapshot, terbium
daniel added a comment. In T138208#7727264 <https://phabricator.wikimedia.org/T138208#7727264>, @Ladsgroup wrote: > Possibly but also keeping the connection open? Maybe it needs to buffer, close the connection and then compress given that it's cpu intensive and slow? WikiExporter writes each chunk of xml to an DumpOutput. In the above case, that would be a DumpBZip2Output, which is a DumpPipeOutput, which uses proc_open to start bzip2 and then writes each chunk to the child process's stdin. The output is far too big to buffer in memory. Writing to disk uncompressed may be an option, bout would require an order of magnitude more disk space. And the wrapper scripts would need to be changed significantly, I suppose. TASK DETAIL https://phabricator.wikimedia.org/T138208 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: LSobanski, Ladsgroup, Marostegui, Addshore, Lydia_Pintscher, daniel, hoo, ArielGlenn, jcrespo, Zppix, karapayneWMDE, Invadibot, maantietaja, jannee_e, Akuckartz, holger.knust, Nandana, Lahi, Gq86, GoranSMilovanovic, Lunewa, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, gnosygnu, 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] T138208: Connections to all db servers for wikidata as wikiadmin from snapshot, terbium
daniel added a comment. In T138208#7727235 <https://phabricator.wikimedia.org/T138208#7727235>, @Ladsgroup wrote: > Most notably the top of the snapshot is not the dumper, it's bzip2. Does it keep connection open while compressing? Isn't it compressing the stream on the fly? TASK DETAIL https://phabricator.wikimedia.org/T138208 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: LSobanski, Ladsgroup, Marostegui, Addshore, Lydia_Pintscher, daniel, hoo, ArielGlenn, jcrespo, Zppix, karapayneWMDE, Invadibot, maantietaja, jannee_e, Akuckartz, holger.knust, Nandana, Lahi, Gq86, GoranSMilovanovic, Lunewa, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, gnosygnu, 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] T284882: Creating a new lexeme always asks for spelling variant for languages without an ISO 639-1 code
daniel added a comment. For the record, I don't remember what specifically went into the decision to rely on ISO-639-1. I have tried to gather some information around the topic. here are some thoughts and observations: - Allowing both ISO-639-1 and ISO-639-3 would mean we'd end up with multiple identifiers for the same language. French could use either "fr" or "fra", and if we allowed ISO-639-2b as well, even "fre". That way, we may end up with multiple terms in the same language, using different code. We'd need to manage a list of aliases for this to work properly. - Using P9753 <https://phabricator.wikimedia.org/P9753> seems like a workable solution, though it kind feels like cheating to me... since it refers to Wikidata itself. - The NewLexeme form is very confusing to me... how would I enter something like de-x-Q2031873 to represent "German with spelling per the 1901 conventions, before the 1996 reform"? It seems to me that the form doesn't allow variants to be entered for a known language. Rather, it asks for a language code if it doesn't know one for the language given. Perhaps the form field should just be called "language code", then? - The Wikidata data model does not specify which codes can be used in language tags. The conceptual model says //"a short string for identifying languages, based on the language preference setting of logged in Wikipedia users. (This might be more similar to BCP 47 but is not necessarily the same either; it is more fine-grained than a GlobalSiteIdentifier) "//. - If I had to design this again, I'd use just Q-Ids internally, and map to language code when generating HTML, RDF, etc. - HTML5 and XML require the `lang` attribute to be BCP47/RFC5646. The specs say //"The lang attribute (in no namespace) specifies the primary language for the element's contents and for any of the element's attributes that contain text. Its value must be a valid BCP 47 language tag, or the empty string."// and //"The values of the attribute are language identifiers as defined by [IETF BCP 47], Tags for the Identification of Languages."// respectively. - RDF Turtle requires language tags to be BCP 47: //"Literals are composed of a lexical form and an optional language tag [BCP47] or datatype IRI."//. - As far as I can determine from a browsing the spec, BCP 47 is a superset of ISO-639-1. It includes //many// codes from ISO-639-2 and ISO-639-3, but only if there wasn't an ISO-639-1 code for it, to avoid ambiguity (see section 2.2.1 item 6). - P305 <https://phabricator.wikimedia.org/P305> is used in Wikidata to refer to BCP 47 language codes. Given all of the above, I would recommends the following to determine the language code for a given item: check P9753 <https://phabricator.wikimedia.org/P9753> (explicit wikidata code), then fall back to P305 <https://phabricator.wikimedia.org/P305> (BCP 47), then fall back to P218 <https://phabricator.wikimedia.org/P218> (ISO-639-1). Do not use P220 <https://phabricator.wikimedia.org/P220> (ISO-639-3), since that might introduce ambiguity. If all else fails, we could still use `mis-x-P` to generate a lanague code for any item, but that may be problematic if a language code is later introduced for that item. All terms would have to be re-tagged. TASK DETAIL https://phabricator.wikimedia.org/T284882 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: daniel, Denny, Mahir256, Lucas_Werkmeister_WMDE, Lydia_Pintscher, Bugreporter, waldyrious, Nikki, Invadibot, maantietaja, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Bodhisattwa, 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] T138208: Connections to all db servers for wikidata as wikiadmin from snapshot, terbium
daniel added a comment. In T138208#7625170 <https://phabricator.wikimedia.org/T138208#7625170>, @Ladsgroup wrote: > I think we have different perspectives and it might be because I'm coming from SRE? I personally think dumps are actually the environment, not the code. I see that point, but I don't want the fix for this issue to be blocked on that discussion. Setting the group from an env variable would be a new approach. Also, forcing the group (rather than changing the default) would be new. I suggest opening a separate ticket for that idea. > Beside the maint. script itself, they basically share the same code as Special:Export and that is being used from the appservers. It shared code, but the access pattern is vastly different. > Currently basically all db queries directly called from wikibase has a dedicated group such as "from-client" or "from-repo". We need something to override that for the sake of reliability. Hm... this is starting to sound like we want consider a set of hints when choosing the replica, rather than specifying a group. Interesting idea. TASK DETAIL https://phabricator.wikimedia.org/T138208 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: LSobanski, Ladsgroup, Marostegui, Addshore, Lydia_Pintscher, daniel, hoo, ArielGlenn, jcrespo, Zppix, Invadibot, maantietaja, jannee_e, Akuckartz, holger.knust, Nandana, Lahi, Gq86, GoranSMilovanovic, Lunewa, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, gnosygnu, 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] T138208: Connections to all db servers for wikidata as wikiadmin from snapshot, terbium
daniel added a comment. In T138208#7612881 <https://phabricator.wikimedia.org/T138208#7612881>, @Ladsgroup wrote: > Thanks, that was the missing piece. My suggestion would be to set an environmental variable in calling mw scripts (if it's not set already). phpunit does a similar thing. And in LB code in mw when trying to get a connection, it should check the env variable and override groups. That would be the cleanest way if you ask me. > > We still have the problem of config reload, how long each stream job usually takes? An environment variable would work, but I think I prefer the idea of setting the group per script. Wikidata's DumpEntities does this, and it makes more sense to me semantically: defaulting to a specific server group is specific to the script's task, not to the environment it runs in. Having a way to tell getBlob to use a different db group, as I suggested earlier, would be nice, but it's rather brittle. We will have to remember to allow such a flag to be passed into all storage layer services. That doesn't seem great. There's a caveat wrt settings $wgDBDefaultGroup in finalSetup(): There is no guarantee that whatever service is going to read that variable hasn't already been instantiated. Specifically note that MWLBFactory will copy the value of DBDefaultGroup, and any modification of the global will have no effect after that. Mid-term, we will need a canonical way for maintenance scripts to set configuration that does not involve global variables. This has to happen after all configuration has been loaded, but before any services have been constructed. Wikidata's DumpEntities uses the MediaWikiServices hook to do that, but it would be nice to make this easier for maintenance scripts. Perhaps finalSetup should just always run in a MediaWikiServices hook? See T275334 <https://phabricator.wikimedia.org/T275334> and T271574 <https://phabricator.wikimedia.org/T271574> for related discussion. TASK DETAIL https://phabricator.wikimedia.org/T138208 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: LSobanski, Ladsgroup, Marostegui, Addshore, Lydia_Pintscher, daniel, hoo, ArielGlenn, jcrespo, Zppix, 786, Suran38, Biggs657, Invadibot, Lalamarie69, maantietaja, Juan90264, Alter-paule, jannee_e, Beast1978, Un1tY, Akuckartz, Hook696, Kent7301, holger.knust, joker88john, CucyNoiD, Nandana, Gaboe420, Giuliamocci, Cpaulf30, Lahi, Gq86, Af420, Bsandipan, GoranSMilovanovic, Lunewa, QZanden, LawExplorer, Lewizho99, Maathavan, _jensen, rosalieper, Scott_WUaS, gnosygnu, 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] T138208: Connections to all db servers for wikidata as wikiadmin from snapshot, terbium
daniel added a comment. In T138208#7568960 <https://phabricator.wikimedia.org/T138208#7568960>, @ArielGlenn wrote: > As I feared, fetchText.php calls MediaWikiServices::getInstance()->getBlobStore()->getBlob() which gets a db replica connection on its own, with no opportunity for us to ask that it be in the vslow/dump group. This can be fixed easily enough. We can just add a parameter to getBlob(), and pass it on to lower layers as appropriate. I'd be happy to work on that with you if you like. The real solution would be not not hit the text table at all any more, but move the external store reference into content_address. We would cut out the middle-table, so to speak. There is no good reason to use the text table when external store is enabled, the only thing that is holding us back is the fact that the migration takes some effort. TASK DETAIL https://phabricator.wikimedia.org/T138208 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: LSobanski, Ladsgroup, Marostegui, Addshore, Lydia_Pintscher, daniel, hoo, ArielGlenn, jcrespo, Zppix, Invadibot, maantietaja, jannee_e, Akuckartz, holger.knust, Nandana, Lahi, Gq86, GoranSMilovanovic, Lunewa, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, gnosygnu, 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] T287650: Stop extending core actions
daniel edited projects, added Platform Team Workboards (MW Expedition); removed Platform Engineering. TASK DETAIL https://phabricator.wikimedia.org/T287650 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Aklapper, eprodromou, daniel, Lucas_Werkmeister_WMDE, DannyS712, Invadibot, maantietaja, Naike, SCIdude, Akuckartz, Soda, pdehaye, Nandana, lucamauri, Lahi, Gq86, Inductiveload, Xover, Andrawaag, GoranSMilovanovic, QZanden, YULdigitalpreservation, LawExplorer, Salgo60, Tshrinivasan, _jensen, rosalieper, Agabi10, Scott_WUaS, Info-farmer, MisterSynergy, abian, Wikidata-bugs, aude, Candalua, Lydia_Pintscher, Tpt, Addshore, Mbch331, 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] T287713: Stop extending core actions in EntitySchema
daniel triaged this task as "Medium" priority. daniel edited projects, added Platform Team Workboards (MW Expedition); removed Platform Engineering. TASK DETAIL https://phabricator.wikimedia.org/T287713 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: DannyS712, Lucas_Werkmeister_WMDE, daniel, Aklapper, Addshore, Invadibot, maantietaja, Naike, SCIdude, Akuckartz, eprodromou, pdehaye, Nandana, Lahi, Gq86, Andrawaag, GoranSMilovanovic, QZanden, YULdigitalpreservation, LawExplorer, Salgo60, _jensen, rosalieper, Agabi10, Scott_WUaS, MisterSynergy, abian, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331, 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] T287714: Stop extending core actions in Wikibase
daniel triaged this task as "Medium" priority. daniel edited projects, added Platform Team Workboards (MW Expedition); removed Platform Engineering. TASK DETAIL https://phabricator.wikimedia.org/T287714 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: DannyS712, Lucas_Werkmeister_WMDE, daniel, Aklapper, Addshore, Invadibot, maantietaja, Naike, Akuckartz, eprodromou, Nandana, lucamauri, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Agabi10, Scott_WUaS, Wikidata-bugs, aude, Mbch331, 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] T288639: SpamBlacklistHooks::onEditFilterMergedContent causes every edit to be rendered twice
daniel added a comment. I agree: keep using WikiPage::prepareContentForEdit() until Id5ba40a21 <https://gerrit.wikimedia.org/r/c/mediawiki/core/+/701074> lands, then start using that. Feedback on that patch would be appreciated. I'm sorry for the confusion that was caused by that deprecation. The original plan was to make WikiPage::getDerivedDataUpdater() public. When we changed that decision, we failed to provide a viable alternative to WikiPage::prepareContentForEdit(). Conceptually, managing the state of an ongoing edit in WikiPage is pretty terrible. But until all the relevant hooks have been changed to pass along all the relevant info, there really is no alternative. TASK DETAIL https://phabricator.wikimedia.org/T288639 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Ladsgroup, daniel Cc: daniel, toan, Michael, Addshore, Lucas_Werkmeister_WMDE, Legoktm, Jdforrester-WMF, Marostegui, ori, Krinkle, Aklapper, dpifke, Ladsgroup, Biggs657, Invadibot, Lalamarie69, maantietaja, Juan90264, Alter-paule, Hazizibinmahdi, Beast1978, Un1tY, Akuckartz, Hook696, Iflorez, Kent7301, alaa_wmde, joker88john, CucyNoiD, Nandana, Gaboe420, Jony, Giuliamocci, Cpaulf30, Lahi, Gq86, Af420, Bsandipan, GoranSMilovanovic, Jayprakash12345, QZanden, LawExplorer, Vali.matei, Lewizho99, Maathavan, _jensen, rosalieper, Scott_WUaS, Wong128hk, Wikidata-bugs, aude, Lydia_Pintscher, Jackmcbarn, 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] T235901: Implement Lua access to Lexemes, Senses and Forms
daniel added a project: Platform Engineering Code Jam. TASK DETAIL https://phabricator.wikimedia.org/T235901 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: daniel, Nikki, Infovarius, Premeditated, Alicia_Fagerving_WMSE, Marsupium, Lucas_Werkmeister_WMDE, Biggs657, Invadibot, Lalamarie69, maantietaja, Juan90264, Alter-paule, Beast1978, Un1tY, Akuckartz, Hook696, Kent7301, joker88john, CucyNoiD, Nandana, Gaboe420, Giuliamocci, Cpaulf30, Lahi, Gq86, Af420, Bsandipan, GoranSMilovanovic, Mahir256, QZanden, LawExplorer, Lewizho99, Maathavan, _jensen, rosalieper, Bodhisattwa, Scott_WUaS, jberkel, Psychoslave, Wikidata-bugs, aude, Shizhao, Nemo_bis, Darkdadaah, Addshore, Mbch331, Ltrlg, 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] T235901: Implement Lua access to Lexemes, Senses and Forms
daniel moved this task from Untriaged to Code Jam on the Platform Engineering Roadmap Decision Making board. daniel added a comment. Tagging as a potential PET Code Jam activity. TASK DETAIL https://phabricator.wikimedia.org/T235901 WORKBOARD https://phabricator.wikimedia.org/project/board/4971/ EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: daniel, Nikki, Infovarius, Premeditated, Alicia_Fagerving_WMSE, Marsupium, Lucas_Werkmeister_WMDE, Biggs657, Invadibot, Lalamarie69, maantietaja, Juan90264, Alter-paule, Beast1978, Un1tY, Akuckartz, Hook696, Kent7301, joker88john, CucyNoiD, Nandana, Gaboe420, Giuliamocci, Cpaulf30, Lahi, Gq86, Af420, Bsandipan, GoranSMilovanovic, Mahir256, QZanden, LawExplorer, Lewizho99, Maathavan, _jensen, rosalieper, Bodhisattwa, Scott_WUaS, jberkel, Psychoslave, Wikidata-bugs, aude, Shizhao, Nemo_bis, Darkdadaah, Mbch331, Ltrlg, 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] T235901: Implement Lua access to Lexemes, Senses and Forms
daniel added a project: Platform Engineering Roadmap Decision Making. TASK DETAIL https://phabricator.wikimedia.org/T235901 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Nikki, Infovarius, Premeditated, Alicia_Fagerving_WMSE, Marsupium, Lucas_Werkmeister_WMDE, Biggs657, Invadibot, Lalamarie69, maantietaja, Juan90264, Alter-paule, Beast1978, Un1tY, Akuckartz, Hook696, Kent7301, joker88john, CucyNoiD, Nandana, Gaboe420, Giuliamocci, Cpaulf30, Lahi, Gq86, Af420, Bsandipan, GoranSMilovanovic, Mahir256, QZanden, LawExplorer, Lewizho99, Maathavan, _jensen, rosalieper, Bodhisattwa, Scott_WUaS, jberkel, Psychoslave, Wikidata-bugs, aude, Shizhao, Nemo_bis, Darkdadaah, Mbch331, Ltrlg, 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] T285795: Decide on languages on EntityStub rdf builders
daniel added a comment. `flavor=dump` is used primarily for updating WDQS, right? In that case, the data is polled because it is know to have changed. So caching seems pointless... TASK DETAIL https://phabricator.wikimedia.org/T285795 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Manuel, Aklapper, Addshore, Lydia_Pintscher, Tarrow, daniel, Lucas_Werkmeister_WMDE, Tonina_Zhelyazkova_WMDE, Ladsgroup, Invadibot, maantietaja, Akuckartz, Iflorez, alaa_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, 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] T283654: CognateIntegrationTest::testCreateDeleteAndRestorePageResultsInEntry is failing
daniel added a project: Platform Team Workboards (MW Expedition). TASK DETAIL https://phabricator.wikimedia.org/T283654 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Lucas_Werkmeister_WMDE, daniel Cc: toan, dang, Lucas_Werkmeister_WMDE, Aklapper, DannyS712, Biggs657, codebug, Invadibot, Lalamarie69, maantietaja, Naike, Alter-paule, Beast1978, Un1tY, Akuckartz, eprodromou, Hook696, Iflorez, Kent7301, alaa_wmde, joker88john, CucyNoiD, Nandana, Gaboe420, Giuliamocci, Cpaulf30, Lahi, Gq86, Af420, Bsandipan, Pablo-WMDE, GoranSMilovanovic, QZanden, LawExplorer, Lewizho99, Maathavan, _jensen, rosalieper, Scott_WUaS, Jonas, Thibaut120094, Wikidata-bugs, aude, Lydia_Pintscher, Darkdadaah, Jdforrester-WMF, Addshore, Mbch331, 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] T285795: Decide on languages on EntityStub rdf builders
daniel added a comment. IIRC the output of Special:EntityData is cacheable in the web cache layer. Cache fragmentation should be considered when deciding on language parameters. Maybe the cache should be bypassed if a parameter is present. Or if more than one language is requested. Or something. Note on the side: it would be nice to turn this into a REST handler at some point. TASK DETAIL https://phabricator.wikimedia.org/T285795 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Manuel, Aklapper, Addshore, Lydia_Pintscher, Tarrow, daniel, Lucas_Werkmeister_WMDE, Tonina_Zhelyazkova_WMDE, Ladsgroup, Invadibot, maantietaja, Akuckartz, Iflorez, alaa_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, 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] T285634: June 2021: appservers accumulating active php-fpm workers, requiring rolling restarts to avoid user-visible latency impact
daniel added a comment. > Scavenging the production logs, we found that Special:EntityData requests for rdf documents were possibly the culprit. Did the code change, or is it just someone is spidering Special:EntityData, hitting that code an awefull lot? TASK DETAIL https://phabricator.wikimedia.org/T285634 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Ladsgroup, daniel Cc: daniel, Addshore, aaron, Joe, Legoktm, Ladsgroup, tstarling, jijiki, Aklapper, Krinkle, CDanis, Dzahn, elukey, King.29, joanna_borun, Invadibot, Zabe, Ramtin0071, Devnull, maantietaja, lmata, wkandek, JMeybohm, Muchiri124, Hazizibinmahdi, Akuckartz, Iflorez, ST47, Yyn1312, brennen, alaa_wmde, RhinosF1, Leonard12345q, Legado_Shulgin, DannyS712, ReaperDawn, Nandana, NebulousIris, Davinaclare77, Qtn1293, Techguru.pc, Imarlier, Lahi, Gq86, GoranSMilovanovic, Th3d3v1ls, Hfbn0, QZanden, LawExplorer, Zppix, _jensen, rosalieper, Liudvikas, Scott_WUaS, Jonas, SBisson, Wong128hk, thcipriani, Wikidata-bugs, aude, Bawolff, ArielGlenn, Lydia_Pintscher, faidon, KartikMistry, He7d3r, Jdforrester-WMF, Mbch331, Jay8g, akosiaris, fgiunchedi ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T204792: [20h] Why is the url key undefined in language objects for categories?
daniel added a comment. We discussed it, and I commented on the patch. The support the general idea (represent language links as objects, not strings, in ParserOutput and OutputPage). The devil is in the detail, though. TASK DETAIL https://phabricator.wikimedia.org/T204792 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: daniel, AMooney, Tonina_Zhelyazkova_WMDE, noarave, Silvan_WMDE, toan, Lucas_Werkmeister_WMDE, Addshore, WMDE-leszek, Lydia_Pintscher, Amire80, Jdlrobson, pmiazga, Aklapper, Invadibot, maantietaja, Naike, Akuckartz, Demian, eprodromou, Iflorez, darthmon_wmde, alaa_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Winter, _jensen, rosalieper, Scott_WUaS, Jonas, Verdy_p, Wikidata-bugs, aude, Jdforrester-WMF, 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] T204792: [20h] Why is the url key undefined in language objects for categories?
daniel added a project: Platform Team Workboards (MW Expedition). daniel added a comment. Putting this on the expedition board, since the proposed patch overlaps with refactoring work we are doing. TASK DETAIL https://phabricator.wikimedia.org/T204792 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: daniel, AMooney, Tonina_Zhelyazkova_WMDE, noarave, Silvan_WMDE, toan, Lucas_Werkmeister_WMDE, Addshore, WMDE-leszek, Lydia_Pintscher, Amire80, Jdlrobson, pmiazga, Aklapper, Invadibot, maantietaja, Naike, Akuckartz, Demian, eprodromou, Iflorez, darthmon_wmde, alaa_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Winter, _jensen, rosalieper, Scott_WUaS, Jonas, Verdy_p, Wikidata-bugs, aude, Jdforrester-WMF, 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] T279063: DBAccessBase is difficult to use with dependency injection
daniel edited projects, added Platform Team Workboards (Clinic Duty Team); removed Platform Engineering. daniel triaged this task as "Low" priority. daniel added a comment. Not high prio for the PET team, but if anyone wants to take it on, please do :) TASK DETAIL https://phabricator.wikimedia.org/T279063 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: daniel, Pchelolo, Lucas_Werkmeister_WMDE, Aklapper, Invadibot, maantietaja, Naike, Akuckartz, eprodromou, Nandana, Banyek, Rayssa-, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Agabi10, Scott_WUaS, Wikidata-bugs, aude, Dinoguy1000, Addshore, Mbch331, Jay8g, WDoranWMF, holger.knust, EvanProdromou ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T43103: initialization of the Language object is very heavy
daniel added a project: Platform Engineering Roadmap Decision Making. daniel added a comment. Tagging this for roadmapping in the light of T247223: Some Meta-Wiki user pages fatal due to OOM from Babel loading too many localisation caches (from cdb/src/Reader/DBA.php) <https://phabricator.wikimedia.org/T247223>. TASK DETAIL https://phabricator.wikimedia.org/T43103 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Reedy, jijiki, Ladsgroup, Marostegui, mxn, Krinkle, Ltrlg, Elitre, Agabi10, adrianheine, gerritbot, Aklapper, Fomafix, Ricordisamoa, Jarekt, Logicwiki, tstarling, Wikidata-bugs, Amire80, siebrand, jeblad, SPQRobin, jayvdb, Denny, DanielFriesen, Nikerabbit, daniel, Af420, CCicalese_WMF, Vali.matei, Srdjan, MuhammadShuaib, Volker_E, LNDDYL, Psychoslave, Dinoguy1000, Gryllida, Shizhao, Arrbee, KartikMistry, Jay8g, RhinosF1 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T279063: DBAccessBase is difficult to use with dependency injection
daniel added a comment. Yea, it's not good to use a base class for this. It should be a trait, or just be removed. TASK DETAIL https://phabricator.wikimedia.org/T279063 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: daniel, Pchelolo, Lucas_Werkmeister_WMDE, Aklapper, Invadibot, maantietaja, Akuckartz, WDoranWMF, holger.knust, EvanProdromou, Nandana, Banyek, Rayssa-, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Agabi10, Scott_WUaS, Wikidata-bugs, aude, Dinoguy1000, Addshore, Mbch331, Jay8g ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T275251: Rest Search API is not wikidata aware (only accepts queries beginning with Q)
daniel added a comment. In T275251#6949064 <https://phabricator.wikimedia.org/T275251#6949064>, @Jdlrobson wrote: >> One long standing issue with the search box on commons is that namespace prefixes do not work. You can't type in "User:..." to search user pages. Since the search box always hits entitysearch, it won't find anything. To fix this, there has to be code somewhere that recognizes namespace prefixes, and based on that decides whether to do a title search or an entity search. Doing this on the client side would be more flexible (e.g. could show both results in separate sections). > > That's tracked in T277363 <https://phabricator.wikimedia.org/T277363>. Not exactly the same issue... or rather, another instance of the same issue. Wikidata has had this problem forever, since searchentities doesn't know about namespaces at all. I'm bringing it up here because the solution to this ticket should somehow address the question of how title-based search in some namespaces might be combined with label based search in other namespaces. Both in the UI and in the API. TASK DETAIL https://phabricator.wikimedia.org/T275251 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: darthmon_wmde, WMDE-leszek, daniel, sdkim, alexhollender, LGoto, Yair_rand, MPhamWMF, ovasileva, Addshore, Lydia_Pintscher, Aklapper, Jdlrobson, Invadibot, Selby, caldera, maantietaja, Akuckartz, Demian, WDoranWMF, holger.knust, EvanProdromou, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, pmiazga, LawExplorer, Winter, JJMC89, Iniquity, _jensen, rosalieper, Agabi10, Scott_WUaS, Pchelolo, Jonas, Volker_E, Niedzielski, Izno, Wikidata-bugs, aude, GWicke, Dinoguy1000, Mbch331, Jay8g ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T275251: Rest Search API is not wikidata aware (only accepts queries beginning with Q)
daniel added a comment. Another fun wrinkle to all this: One long standing issue with the search box on commons is that namespace prefixes do not work. You can't type in "User:..." to search user pages. Since the search box always hits entitysearch, it won't find anything. To fix this, there has to be code somewhere that recognizes namespace prefixes, and based on that decides whether to do a title search or an entity search. Doing this on the client side would be more flexible (e.g. could show both results in separate sections). TASK DETAIL https://phabricator.wikimedia.org/T275251 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: darthmon_wmde, WMDE-leszek, daniel, sdkim, alexhollender, LGoto, Yair_rand, MPhamWMF, ovasileva, Addshore, Lydia_Pintscher, Aklapper, Jdlrobson, Invadibot, Selby, caldera, maantietaja, Akuckartz, Demian, WDoranWMF, holger.knust, EvanProdromou, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, pmiazga, LawExplorer, Winter, JJMC89, Iniquity, _jensen, rosalieper, Agabi10, Scott_WUaS, Pchelolo, Jonas, Volker_E, Niedzielski, Izno, Wikidata-bugs, aude, GWicke, Dinoguy1000, Mbch331, Jay8g ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T275251: Rest Search API is not wikidata aware (only accepts queries beginning with Q)
daniel added a comment.
In T275251#6947445 <https://phabricator.wikimedia.org/T275251#6947445>,
@Jdlrobson wrote:
> I understand and I'm saying that this could be implemented using an
abstracted PHP interface which provides a contract for the format in the
response, without having any knowledge of the implementation.
That is possible, but I don't see the point. Why add another layer of
indirection in order to make the same endpoint to two different things?
> When I mean spec, I'm referring to the output API.
The format of the output is one part of the contract. The other part is the
relationship between the input and the output, which is defined as "title
prefix". To accommodate the Wikibase use case, it would have to be softened to
"some kind of match to an identifier of the page" (doesn't have to be the
title, but it's not full text either).
I'd rather not weaken the contract of the existing endpoint. I'd prefer a
separate endpoint, that has a compatible output format.
> If an API was created that returned data in the same format, the search UI
would mostly function.
Yes, mostly. The question is whether that's good enough. I recall that we
invested quite a bit of work into getting additional information into the
search popup.
For example, if I type "تهران" into the search box on wikidata.org, the API
responds with entries like this:
{
"id":"Q643031",
"title":"Q643031",
"pageid":605069,
"repository":"wikidata",
"url":"//www.wikidata.org/wiki/Q643031",
"concepturi":"http://www.wikidata.org/entity/Q643031";,
"label":"Tehran County",
"description":"county in Tehran, Iran",
"match":{
"type":"label",
"language":"ps",
"text":"\u062a\u0647\u0631\u0627\u0646
\u0648\u0644\u0633\u0648\u0627\u0644\u06cd"
},
"aliases":[
"\u062a\u0647\u0631\u0627\u0646
\u0648\u0644\u0633\u0648\u0627\u0644\u06cd"
]
},
Note the "match" and "aliases" keys, and note the rendering of the matched
alias in the popup, separate from the disambiguating description, with correct
LTR orientation:
F34191649: Bildschirmfoto von 2021-03-26 11-32-54.png
<https://phabricator.wikimedia.org/F34191649>
Extra info like this can be added to the search/title endpoint, the output is
extensible. It could also be returned from a separate endpoint. But the UI
would also need to use it, that's why I was suggesting a separate UI component.
Anyway, assessing the importance of this is up to the Wikidata folks. I'm more
concerned with the contract of the `search/title` endpoint.
> The implementation can be completely different, living in Wikidata if
necessary. Right now, we allow configuration on the host level, but if this is
the direction we want to take, we can make the path configurable our side to to
support this.
For the "same UI, different backend" solution, that would work. The big
question is whether Wikidata is OK with "same UI", loosing the extra fatures.
TASK DETAIL
https://phabricator.wikimedia.org/T275251
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: darthmon_wmde, WMDE-leszek, daniel, sdkim, alexhollender, LGoto, Yair_rand,
MPhamWMF, ovasileva, Addshore, Lydia_Pintscher, Aklapper, Jdlrobson, Invadibot,
Selby, caldera, maantietaja, Akuckartz, Demian, WDoranWMF, holger.knust,
EvanProdromou, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden,
pmiazga, LawExplorer, Winter, JJMC89, Iniquity, _jensen, rosalieper, Agabi10,
Scott_WUaS, Pchelolo, Jonas, Volker_E, Niedzielski, Izno, Wikidata-bugs, aude,
GWicke, Dinoguy1000, Mbch331, Jay8g
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T275251: Rest Search API is not wikidata aware (only accepts queries beginning with Q)
daniel added a comment. In T275251#6945709 <https://phabricator.wikimedia.org/T275251#6945709>, @Jdlrobson wrote: > Please no more UI components.. that would be a maintenance disaster as Wikidata would need to do this for every skin (we plan to use this same Vue component inside the Minerva skin). I don't have super strong feelings about that, I just remember that Wikibase search shows a lot more info than what the "normal" search popup shows. The data fields are not the same (label, matched alias, description, matches in different languages potentially using different directionality), and it seems like additional structuring will be needed to accommodate Lexemes etc. If I recall correctly, the main problem was that the custom search box was hacked into the skin in a horrible way. Perhaps that could be improved. > The API used by the existing UI component is configurable so theoretically, Wikidata could have its own API which returns data using the same spec with the right level of abstraction. I think this might be a better approach then rebuilding the UI and all the complexity that would go with it. The problem is that Wikibase can't really use the same spec. It needs quite a bit of extra info from the search backend in order to do what it does. At least, that's what I recall from shoehorning this in many years ago. TASK DETAIL https://phabricator.wikimedia.org/T275251 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: darthmon_wmde, WMDE-leszek, daniel, sdkim, alexhollender, LGoto, Yair_rand, MPhamWMF, ovasileva, Addshore, Lydia_Pintscher, Aklapper, Jdlrobson, Invadibot, Selby, caldera, maantietaja, Akuckartz, Demian, WDoranWMF, holger.knust, EvanProdromou, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, pmiazga, LawExplorer, Winter, JJMC89, Iniquity, _jensen, rosalieper, Agabi10, Scott_WUaS, Pchelolo, Jonas, Volker_E, Niedzielski, Izno, Wikidata-bugs, aude, GWicke, Dinoguy1000, Mbch331, Jay8g ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T275251: Rest Search API is not wikidata aware (only accepts queries beginning with Q)
daniel added a comment. I'm unconvinced that hooking into SearchHandler is the Right Thing. The endpoint is `/v1/search/title`, making that do anything but title auto-completion would be confusing, it would break the contract. I'd also argue that we will still want title auto-completion for some namespaces. The desired behavior for the search box in Wikidata differs significantly from the expected behavior for vanilla MediaWiki. The behavior could even depend on the namespace the user is currently in, or offer results from different namespaces in sections or side by side. In my mind, it should be a different UI component, backed by a dedicated API. The way we hacked this into the skin in the past was rather nasty, perhaps a better mechanism can be found. Alternatively, Wikibase can hook into search index generation to change what the "page title" is for items. But the multi-lingual nature of Wikibase labels makes that hard. TASK DETAIL https://phabricator.wikimedia.org/T275251 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: daniel, sdkim, alexhollender, LGoto, Yair_rand, MPhamWMF, ovasileva, Addshore, Lydia_Pintscher, Aklapper, Jdlrobson, Invadibot, Selby, caldera, maantietaja, Akuckartz, Demian, darthmon_wmde, WDoranWMF, holger.knust, EvanProdromou, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, pmiazga, LawExplorer, Winter, JJMC89, Iniquity, _jensen, rosalieper, Agabi10, Scott_WUaS, Pchelolo, Jonas, Volker_E, Niedzielski, Izno, Wikidata-bugs, aude, GWicke, Dinoguy1000, Mbch331, Jay8g ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T214362: RFC: Store WikibaseQualityConstraint check data in persistent storage
daniel added a subscriber: Naike. daniel added a comment. In T214362#6921322 <https://phabricator.wikimedia.org/T214362#6921322>, @Addshore wrote: > It looks like we would be able to use the ParserCache for this one T270710: Allow values other than ParserOutput to be stored in a ParserCache instance <https://phabricator.wikimedia.org/T270710> is done? Yes, but that's not on any roadmap currently. If you want it prioritized, please reach out to @Naike so she can slot it into our process. > So I guess the scope of this RFC would then switch to, is it okay to use the parser cache for this? Conceptually I think this is the correct thing to do. But there are oprational considerations - if this adds a considerable amount of data to the storage that backs the parser cache, this needs to be planned. Scaling the parser cache backend storage is currently a very manual and slow process. TASK DETAIL https://phabricator.wikimedia.org/T214362 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Naike, Ottomata, JeroenDeDauw, Michael, WMDE-leszek, eprodromou, CCicalese_WMF, kchapman, Krinkle, mobrovac, abian, Lydia_Pintscher, Lucas_Werkmeister_WMDE, Marostegui, Joe, daniel, Agabi10, Aklapper, Addshore, maantietaja, Akuckartz, Demian, DannyS712, Nandana, kostajh, Lahi, Gq86, GoranSMilovanovic, RazeSoldier, QZanden, merbst, LawExplorer, _jensen, rosalieper, xSavitar, Scott_WUaS, Izno, SBisson, Perhelion, Wikidata-bugs, Base, aude, GWicke, Bawolff, jayvdb, fbstj, santhosh, Jdforrester-WMF, Ladsgroup, Mbch331, Jay8g, Ltrlg, bd808, Legoktm ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T276551: Allow extensions to use NameTableStore for their own tables
daniel added a subscriber: tstarling. daniel added a comment. @tstarling rememberd that we were discussing this exact thing when he worked on NameTabelStoreFactory: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/455487/4 I think his suggestion at the time was to gave a newFromSpec() method that would take an array like the ones we define in self::$info. TASK DETAIL https://phabricator.wikimedia.org/T276551 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: tstarling, daniel, BPirkle, Addshore, Aklapper, Lucas_Werkmeister_WMDE, maantietaja, Akuckartz, WDoranWMF, holger.knust, EvanProdromou, Nandana, Banyek, Rayssa-, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Agabi10, Scott_WUaS, Pchelolo, abian, Wikidata-bugs, aude, Dinoguy1000, Mbch331, Jay8g ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T276551: Allow extensions to use NameTableStore for their own tables
daniel added a comment. NameTableStore can become newable. The fact that it 's not is just an oversight from my point of view. I'd be reluctant to make it // stable to extend//, though. NameTableStoreFactory is conceptually questionable - different NameTableStore instances may be used for totally different things, so NameTableStoreFactory is bound to cross domain boundaries. The way it's currently used it's really bound to the revision storage backend. Perhaps the could be a base class or a trait or a helper that would make it easy to implement separate factories for different use cases of NameTableStore. TASK DETAIL https://phabricator.wikimedia.org/T276551 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: daniel, BPirkle, Addshore, Aklapper, Lucas_Werkmeister_WMDE, maantietaja, Akuckartz, WDoranWMF, holger.knust, EvanProdromou, Nandana, Banyek, Rayssa-, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Agabi10, Scott_WUaS, Pchelolo, abian, Wikidata-bugs, aude, Dinoguy1000, Mbch331, Jay8g ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T277362: Deprecation warning client-repo wikitext link
daniel added a comment. Thank you for your response, @brennen! In T277362#6922054 <https://phabricator.wikimedia.org/T277362#6922054>, @brennen wrote: > 1. Deployers have no way to know in the moment that something is only a deprecation warning with no other consequences. If a warning isn't material to production health, it should probably either be labeled in a way that makes that extremely clear, or be sent to some channel that isn't surfaced where deployers are looking for signs of production breakage. In my mind, deprecation warnings should never be material to production health. They exist in order to warn //before// things break. So perhaps they should be channeled elsewhere. But we would have to make sure that they are still noticed, and bugs still get filed. They should definitely not be ignored or allowed to pile up. > 2. If there's ever a conversation about whether something might become a train blocker, RelEng would greatly appreciate if we were looped into the discussion by having it surfaced on the blocker task. Please see Deployments/Risky change template <https://wikitech.wikimedia.org/wiki/Deployments/Risky_change_template>. We can and will improve our documentation about this. (See T273802 <https://phabricator.wikimedia.org/T273802>.) Duly noted. We had a couple of such risky patches a while ago, around ParserCache. We did not think of this patch here as risky, precisely because it only introduced warnings, and did not break behavior. > 3. It is undeniably true that we sometimes halt the train on things which are "only" logspam. Partly this is because it's hard for us to tell the difference without developer input. Partly this is because halting the train is the only way we can get enough of them fixed to keep production logspam down to tolerable levels. I'm not complaining that it's broken, I'm thinking about ways to improve it. And there are certainly different kinds of "warnings" - e.g. a "notice" about accessing an undefined array key may have very serious implications, depending on how that value is being used. I'm trying to think of a better channel for things that should be fixed asap but are not a danger to the life site. Fixing deprecation warnings isn't nice to have, it should be high priority. But it's not UBN, and it should not block the train. Maybe a separate log channel would be the way to go. TASK DETAIL https://phabricator.wikimedia.org/T277362 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Ladsgroup, daniel Cc: thcipriani, dancy, Legoktm, RhinosF1, brennen, Lucas_Werkmeister_WMDE, Ladsgroup, Addshore, hoo, daniel, WMDE-leszek, toan, Aklapper, maantietaja, Hazizibinmahdi, Akuckartz, Iflorez, alaa_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, abian, 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] T277362: Deprecation warning client-repo wikitext link
daniel added a subscriber: thcipriani. daniel added a comment. In T277362#6920796 <https://phabricator.wikimedia.org/T277362#6920796>, @WMDE-leszek wrote: > It is indeed very unfortunate that there has not been automated tests for this functionality. It would have given the issue more visibility and faster. > WMDE has created tests for this recently -- this is how we identified the problem on Monday -- but he have not yet integrated it into Wikimedia Jenkins CI. I expect us to do this in a couple of weeks. Oh, that's excellent! I'm curious about what approach you took for these tests. Having them in CI would have prevented to offending code from being merged. > If blocking the train on this issue -- which, BTW, got ultimately triggered by T277593 <https://phabricator.wikimedia.org/T277593> - WMDE has been the whole day going back and forth in internal chats whether this is a train blocker or whether all will be fine when the code lands in production -- was too extreme, it maybe would be good to have some clarity on how those deprecation warnings, and the exceptions/errors logged stemming from them should be treated. In my eyes treating them as a train blocker has been in line with the recently announced "new line on logspam". I generally agree with the stricter line on logspam. But I do think that halting the train for deprecation warnings does more harm than good. Perhaps @brennen and @thcipriani can chime in on that. Generally, halting/reverting deployments should be done to prevent damage to the site. Halting/reverting on logspam seems like a desperate measure, intended to make sure that warnings in production are actually prioritized. In this case, the warning was harmless (deprecation warnings indicate that things are still working properly), and the issue was already being worked on. Halting the train just caused more work for more people. > Point taken, we should have been more active in communication about this problem outside of WMDE (virtual) office. Something we shall improve in the future. I notice that neither this task nor T277593 <https://phabricator.wikimedia.org/T277593> is on any PET board, and I wasn't pinged on the task, even though it became quickly clear that the cause was in core. Pinging the relevant teams on components (in this case, #mediawiki-revision-backend <https://phabricator.wikimedia.org/tag/mediawiki-revision-backend/> and #platform_engineering <https://phabricator.wikimedia.org/tag/platform_engineering/>) would have helped getting more attention on this more quickly, and to coordinate on the way forward. TASK DETAIL https://phabricator.wikimedia.org/T277362 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Ladsgroup, daniel Cc: thcipriani, dancy, Legoktm, RhinosF1, brennen, Lucas_Werkmeister_WMDE, Ladsgroup, Addshore, hoo, daniel, WMDE-leszek, toan, Aklapper, maantietaja, Hazizibinmahdi, Akuckartz, Iflorez, alaa_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, abian, 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] T277362: Deprecation warning client-repo wikitext link
daniel added a comment. In T277362#6919927 <https://phabricator.wikimedia.org/T277362#6919927>, @Legoktm wrote: > It just pushes the problem onto someone else, by stopping their development and forcing them drop everything just to unbreak their repo I was not aware this broke any tests in any repo - did it? My understanding was that there are no automated tests for the cross-wiki case in Wikibase. Because there are no such tests, the issue did not show up in CI. I have been wanting to improve this situation for quite a while. Perhaps incidents like this one can help to explain why we need to improve our testing platform. Some relevant tickets: T261848: Simulate databases for sister sites in phpunit <https://phabricator.wikimedia.org/T261848>, T248683: Create and run a suite of end-to-end tests for the Wikimedia environment <https://phabricator.wikimedia.org/T248683>, T195932: Test all MediaWiki tarball extensions in gate for all changes to MediaWiki and each other <https://phabricator.wikimedia.org/T195932>. > - in this case it hit everyone by stopping the entire train. I don't see why deprecation warnings should stop the train at all. I agree that they should be worked on with high priority, but why should they be treated as production errors? > That Wikimedia-deployed code was still using this hard deprecated code was identified on Saturday, once that identification was done, why did it have to rise all the way to a train blocker on Tuesday to get a revert? I learned about the issue from Hoo on IRC at 17:30 on Monday. I immediately started work on a fix. On Tuesday, that fix got a couple of rounds of review, getting the tests right wasn't trivial. However, the urgency wasn't clear at all, I didn't hear from the wikidata team all day. TASK DETAIL https://phabricator.wikimedia.org/T277362 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Ladsgroup, daniel Cc: dancy, Legoktm, RhinosF1, brennen, Lucas_Werkmeister_WMDE, Ladsgroup, Addshore, hoo, daniel, WMDE-leszek, toan, Aklapper, maantietaja, Hazizibinmahdi, Akuckartz, Iflorez, alaa_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, abian, 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] T277362: Deprecation warning client-repo wikitext link
daniel added a comment. For context - the description is of T275531 <https://phabricator.wikimedia.org/T275531> is indeed rather short, and the real background is in T273284 <https://phabricator.wikimedia.org/T273284>. The idea is that we to avoid data corruption such as T260485 <https://phabricator.wikimedia.org/T260485>, we have to ensure that cross-wiki operations on entities such as users, pages, and revisions are safe. We do that by asserting that they belong to the correct wiki. Title is not cross-wiki aware, so using it in a cross-wiki context was deprecated. I agree that it was impossible to discover this idea from the deprecation message, and in this case it was also not discoverable from the task linked in the commit message. I propose we think about how we can minimize disruption by improving how we log deprecation messages, and improve communication by making the relevant information more discoverable in context. Please let me know if you have ideas. TASK DETAIL https://phabricator.wikimedia.org/T277362 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: dancy, Legoktm, RhinosF1, brennen, Lucas_Werkmeister_WMDE, Ladsgroup, Addshore, hoo, daniel, WMDE-leszek, toan, Aklapper, maantietaja, Alter-paule, Beast1978, Un1tY, Akuckartz, Hook696, Iflorez, Kent7301, alaa_wmde, joker88john, CucyNoiD, Nandana, Gaboe420, Giuliamocci, Cpaulf30, Lahi, Gq86, Af420, Bsandipan, GoranSMilovanovic, QZanden, LawExplorer, Lewizho99, Maathavan, _jensen, rosalieper, Scott_WUaS, Jonas, abian, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331, AMooney ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T277362: Deprecation warning client-repo wikitext link
daniel added a comment. > I also notice that MediaWiki core has again hard-deprecated code that is still used in Wikimedia-maintained code even though the stable interface policy forbids this This was of course not intentional - the policy asks for hard deprecation to happen as soon as all callers have been fixed. Which of course in practice means as soon as we //think// all callers have been fixed. The problem is that it's sometimes hard to find such code - and sometimes it's only found when it starts logging deprecation warnings in production. > That's not a valid reason to bypass the deprecation policy. In the past we just added logging for it (e.g. T176526 <https://phabricator.wikimedia.org/T176526>: Remove $wgTitle fallback from EditPage in MW1.36) until we were satisfied we had caught everything. Technically, deprecation warnings //are// logging. I can see that it would be preferable to start out with a lower log level, so these don't show up as production errors. But using "soft" logging means these issues don't show up as test failures. The fact that deprecation warnings make tests fail is very helpful for finding any cases we missed by looking at the code. Perhaps the solution is to handle deprecation warnings separate from other production issues? Anyway, the "proper" fix done, I'll clean up the remaining issues in the tests tomorrow: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/672499 TASK DETAIL https://phabricator.wikimedia.org/T277362 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: dancy, Legoktm, RhinosF1, brennen, Lucas_Werkmeister_WMDE, Ladsgroup, Addshore, hoo, daniel, WMDE-leszek, toan, Aklapper, maantietaja, Alter-paule, Beast1978, Un1tY, Akuckartz, Hook696, Iflorez, Kent7301, alaa_wmde, joker88john, CucyNoiD, Nandana, Gaboe420, Giuliamocci, Cpaulf30, Lahi, Gq86, Af420, Bsandipan, GoranSMilovanovic, QZanden, LawExplorer, Lewizho99, Maathavan, _jensen, rosalieper, Scott_WUaS, Jonas, abian, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331, AMooney ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T139912: Take care of disambiguation items at Wikidata
Daniel-Barrows added a comment. Relevant discussion has been archived at https://www.wikidata.org/wiki/Wikidata:Bot_requests/Archive/2017/2#Take_care_of_disambiguation_items TASK DETAIL https://phabricator.wikimedia.org/T139912 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Daniel-Barrows Cc: Daniel-Barrows, Stryn, matej_suchanek, Aklapper, Esc3300, Zppix, maantietaja, Akuckartz, Dinadineke, DannyS712, Nickleh, Nandana, tabish.shaikh91, Lahi, Gq86, GoranSMilovanovic, Soteriaspace, Jayprakash12345, JakeTheDeveloper, QZanden, merbst, LawExplorer, _jensen, rosalieper, Scott_WUaS, abian, Wikidata-bugs, aude, Dinoguy1000, TheDJ, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T273622: Deprecation warning: Expected RevisionRecord to belong to ...
daniel added a comment. @Lucas_Werkmeister_WMDE wrote: > so for a RevisionRecord belonging to a non-local wiki, calling getId() without arguments will now trigger a call to wfDeprecatedMsg(). But wfDeprecatedMsg() is apparently enough to make unit tests fail, and also cause warnings to be displayed in the page output, so I assume it counts as hard deprecation. Shouldn’t there have been a period of soft deprecation in between? Soft deprecation is for the period between deciding that some code or behavior should be removed, and removing all known callers. I didn't spot the callers in Wikibase code, though I suspected they exist. We decided to add the deprecation warning to find any remaining callers. I told Adam to look out for that during our lunch meeting last week. I'm sorry for causing you work. Unfortunately, there didn't seem to be a good way to flush these issues out beforehand - afterall, Wikibase CI tests passed. Note that as far as I know, Wikibase the the only extension that currently uses cross-wiki support on RevisionStore. So this is hopefully the only thing broken by this change. TASK DETAIL https://phabricator.wikimedia.org/T273622 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Lucas_Werkmeister_WMDE, daniel Cc: hashar, WMDE-leszek, RhinosF1, Peter.ovchyn, Vlad.shapik, Lucas_Werkmeister_WMDE, Pchelolo, daniel, Addshore, toan, Aklapper, Alter-paule, Beast1978, Un1tY, Akuckartz, Hook696, Iflorez, darthmon_wmde, WDoranWMF, Kent7301, alaa_wmde, holger.knust, EvanProdromou, joker88john, CucyNoiD, Nandana, Gaboe420, Giuliamocci, Cpaulf30, Lahi, Gq86, Af420, Bsandipan, GoranSMilovanovic, QZanden, LawExplorer, Lewizho99, Maathavan, _jensen, rosalieper, Agabi10, Scott_WUaS, Jonas, Verdy_p, Wikidata-bugs, aude, Lydia_Pintscher, Jdforrester-WMF, Mbch331, Rxy, Jay8g ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T245989: RecetChanges query API fails with timeout when asking for 5 RC redirects in on Wikidata
daniel renamed this task from "Wikidata API fails with timeout when asking for 5 RC redirects" to "RecetChanges query API fails with timeout when asking for 5 RC redirects in on Wikidata". TASK DETAIL https://phabricator.wikimedia.org/T245989 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Masti, Marostegui, Aklapper, pywikibot-bugs-list, Dvorapa, JohnsonLee01, SHEKH, Naike, Dijkstra, Khutuck, Akuckartz, Zkhalido, eprodromou, WDoranWMF, Viztor, DannyS712, Nandana, Wenyi, Amorymeltzer, Lahi, Gq86, GoranSMilovanovic, QZanden, Tbscho, MayS, LawExplorer, Sethakill, Mdupont, JJMC89, dg711, _jensen, rosalieper, Agabi10, Altostratus, Avicennasis, Scott_WUaS, Pchelolo, mys_721tx, Wikidata-bugs, aude, jayvdb, Alchimista, Mbch331, Rxy ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T113034: RFC: Overhaul Interwiki map, unify with Sites and WikiMap
daniel lowered the priority of this task from "High" to "Medium". TASK DETAIL https://phabricator.wikimedia.org/T113034 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Addshore, Ladsgroup, kchapman, Lucas_Werkmeister_WMDE, PokestarFan, Koavf, Billinghurst, dcausse, cscott, Jakob_WMDE, WMDE-leszek, Lydia_Pintscher, Liuxinyu970226, MarcoAurelio, gerritbot, Quiddity, Bene, hoo, zhuyifei1999, jayvdb, Isarra, Smalyshev, Ltrlg, GWicke, Ricordisamoa, MZMcBride, Krenair, MrStradivarius, Legoktm, TTO, ori, aaron, Aklapper, daniel, Akuckartz, Demian, WDoranWMF, holger.knust, EvanProdromou, DannyS712, Nandana, kostajh, Lahi, Gq86, GoranSMilovanovic, RazeSoldier, QZanden, LawExplorer, TomT0m, _jensen, rosalieper, Agabi10, xSavitar, Scott_WUaS, Pchelolo, Izno, SBisson, Wong128hk, Luke081515, Perhelion, Wikidata-bugs, Base, aude, Bawolff, fbstj, santhosh, Jdforrester-WMF, Mbch331, Rxy, Jay8g, bd808 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T214362: RFC: Store WikibaseQualityConstraint check data in persistent storage
daniel added a comment. In T214362#6653148 <https://phabricator.wikimedia.org/T214362#6653148>, @Addshore wrote: > It's a shame that this has made its way into the "icebox" of the #platform_engineering_roadmap_decision_making <https://phabricator.wikimedia.org/tag/platform_engineering_roadmap_decision_making/> board. To clarify: It's unfortunately not very clear, but "idebox" doesn't mean "we definitely won't do it". It just means "not currently on our roadmap". If it's important to someone, it can be taken out of the icebox. It's basically a matter of discussing priorities and collaboration between teams. TASK DETAIL https://phabricator.wikimedia.org/T214362 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: eprodromou, CCicalese_WMF, kchapman, Krinkle, mobrovac, abian, Lydia_Pintscher, Lucas_Werkmeister_WMDE, Marostegui, Joe, daniel, Agabi10, Aklapper, Addshore, Akuckartz, Demian, WDoranWMF, holger.knust, EvanProdromou, DannyS712, Nandana, kostajh, Lahi, Gq86, Pablo-WMDE, GoranSMilovanovic, RazeSoldier, QZanden, merbst, LawExplorer, _jensen, rosalieper, xSavitar, Scott_WUaS, Pchelolo, Izno, SBisson, Perhelion, Wikidata-bugs, Base, aude, GWicke, Bawolff, jayvdb, fbstj, santhosh, Jdforrester-WMF, Ladsgroup, 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] T237991: Changes to Structured Data on Commons should trigger page refresh
daniel added a project: User-Daniel. TASK DETAIL https://phabricator.wikimedia.org/T237991 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Keegan, Cparle, Multichill, matthiasmullie, Ramsey-WMF, AntiCompositeNumber, Tgr, Addshore, Jarekt, Aklapper, Mohammadmalek554, CBogen, Akuckartz, keithbrianpadilla, Saimongoltinio, WikimeSteve, ppelberg, Nandana, JKSTNK, marcella, Revansx, OhKayeSierra, takidelfin, Lahi, PDrouin-WMF, Gq86, E1presidente, Necroarcano, Anooprao, SandraF_WMF, Robinma, GoranSMilovanovic, QZanden, Tramullas, Acer, merbst, LawExplorer, Salgo60, Silverfish, Wess, Dvorapa, Poyekhali, _jensen, rosalieper, Taiwania_Justo, Scott_WUaS, Srdjan, Susannaanas, Ixocactus, Wong128hk, Jrf, Husun1297, Jane023, Wikidata-bugs, Base, aude, El_Grafo, Dinoguy1000, Ricordisamoa, Mvolz, Wesalius, Swainr, daniel, Lydia_Pintscher, thiemowmde, Fabrice_Florin, Raymond, Steinsplitter, Mbch331, Jay8g ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T67267: Specify whether TimeValue stores timestamps in UTC or local time.
daniel removed daniel as the assignee of this task. TASK DETAIL https://phabricator.wikimedia.org/T67267 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: PokestarFan, Jc3s5h, Wikidata-bugs, Lydia_Pintscher, daniel, JohnLewis, Akuckartz, Nandana, lucamauri, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T194736: Implement automatic conflict resolution for all slots [MCR]
daniel removed daniel as the assignee of this task. daniel added a project: User-Daniel. TASK DETAIL https://phabricator.wikimedia.org/T194736 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Aklapper, Agabi10, TomT0m, Smalyshev, -jem-, daniel, Naike, Akuckartz, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, JJMC89, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Jdforrester-WMF, Mbch331, Ltrlg ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T205459: Decide how SlotRoleHandlers can provide placeholders for missing slots
daniel added a project: User-Daniel. daniel removed daniel as the assignee of this task. TASK DETAIL https://phabricator.wikimedia.org/T205459 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Cparle, Aklapper, gerritbot, daniel, Naike, CBogen, Akuckartz, DannyS712, Nandana, Lahi, Gq86, Ramsey-WMF, GoranSMilovanovic, QZanden, LawExplorer, JJMC89, _jensen, rosalieper, Agabi10, Scott_WUaS, Wikidata-bugs, aude, Jdforrester-WMF, Mbch331, Ltrlg ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T260232: BatchRowIterator slow query on commonswiki
daniel edited projects, added Platform Team Workboards (Clinic Duty Team); removed Platform Team Workboards (External Code Reviews). TASK DETAIL https://phabricator.wikimedia.org/T260232 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: ArielGlenn, CBogen, Cparle, Umherirrender, DannyS712, Naike, WDoranWMF, Krinkle, aaron, Reedy, Ladsgroup, Aklapper, Marostegui, XeroS_SkalibuR, Alter-paule, jannee_e, Beast1978, Un1tY, Akuckartz, eprodromou, Hook696, Adidsone1, darthmon_wmde, Kent7301, joker88john, CucyNoiD, Nandana, Namenlos314, Gaboe420, Phukettaxigroup, Giuliamocci, Cpaulf30, Lahi, Gq86, Af420, Ramsey-WMF, Darkminds3113, Bsandipan, Lucas_Werkmeister_WMDE, GoranSMilovanovic, Jayprakash12345, Lunewa, QZanden, EBjune, merbst, LawExplorer, Vali.matei, Lewizho99, Maathavan, _jensen, rosalieper, Agabi10, Scott_WUaS, Pchelolo, Jonas, Xmlizer, Volker_E, gnosygnu, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, GWicke, Dcljr, Dinoguy1000, Manybubbles, Mbch331, Rxy, Jay8g, Ltrlg ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T257196: Allow tests to reset/clear non-legacy hook handlers
daniel added a comment. The fix for T255056 <https://phabricator.wikimedia.org/T255056> should address this as well. TASK DETAIL https://phabricator.wikimedia.org/T257196 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: daniel, Gehel, CBogen, Lucas_Werkmeister_WMDE, Aklapper, Wilmanbeno, Akuckartz, darthmon_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, jayvdb, Mbch331, jeremyb ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T257196: Allow tests to reset/clear non-legacy hook handlers
daniel closed this task as a duplicate of T255056: MediaWikiIntegrationTestCase::setTemporaryHook needs to support new style hooks . TASK DETAIL https://phabricator.wikimedia.org/T257196 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Gehel, CBogen, Lucas_Werkmeister_WMDE, Aklapper, Wilmanbeno, Akuckartz, darthmon_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, jayvdb, Mbch331, jeremyb ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T254688: SpecialWhatLinksHere::showIndirectLinks on wikidatawiki needs optimizing
daniel added a comment. In T254688#6406171 <https://phabricator.wikimedia.org/T254688#6406171>, @Lydia_Pintscher wrote: > Ok thanks. That special page is rather important for Wikidata and turning it off completely is not an option I fear. My idea was to turn of the "indirect links" feature. Direct links would still be shown, but links via redirects would not. TASK DETAIL https://phabricator.wikimedia.org/T254688 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: aaron, daniel Cc: daniel, Lydia_Pintscher, Ladsgroup, Addshore, Aklapper, Marostegui, Akuckartz, darthmon_wmde, WDoranWMF, holger.knust, EvanProdromou, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Agabi10, Scott_WUaS, Pchelolo, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T254688: SpecialWhatLinksHere::showIndirectLinks on wikidatawiki needs optimizing
daniel added a comment. In T254688#6405484 <https://phabricator.wikimedia.org/T254688#6405484>, @Marostegui wrote: > The only workaround we've found is sadly, using `FORCE`, `USE` or `IGNORE INDEX` on the queries to bypass those issues. Sometimes issues get fixed by running an `analyze` table so the optimizer gets recent table stats, or just from one version to another. Yea, the question is, what to force. The index that seems off in the query plan you supplied is `page_len`. That makes no sense. But forcing it to use `PRIMARY` there makes things worse: > explain SELECT /* SpecialWhatLinksHere::showIndirectLinks */ page_id,page_namespace,page_title,rd_from,rd_fragment,page_is_redirect FROM (SELECT pl_from,rd_from,rd_fragment FROM `pagelinks` LEFT JOIN `redirect` ON ((rd_from = pl_from) AND rd_title = 'P248' AND (rd_interwiki = '' OR rd_interwiki IS NULL) AND rd_namespace = 120) JOIN `page` use index (primary) ON ((pl_from = page_id)) WHERE pl_namespace = 120 AND pl_title = 'P248' ORDER BY pl_from LIMIT 102 ) `temp_backlink_range` JOIN `page` on ((pl_from = page_id))ORDER BY page_id LIMIT 51; +--+-+++--+-+-+---+--+--+ | id | select_type | table | type | possible_keys| key | key_len | ref | rows | Extra | +--+-+++--+-+-+---+--+--+ |1 | PRIMARY | | ALL| NULL | NULL | NULL| NULL | 102 | Using temporary; Using filesort | |1 | PRIMARY | page | eq_ref | PRIMARY | PRIMARY | 4 | temp_backlink_range.pl_from |1 | | |2 | DERIVED | page | index | PRIMARY | PRIMARY | 4 | NULL | 90571878 | Using index; Using temporary; Using filesort | |2 | DERIVED | pagelinks | eq_ref | PRIMARY,pl_namespace | PRIMARY | 265 | wikidatawiki.page.page_id,const,const |1 | Using where; Using index | |2 | DERIVED | redirect | eq_ref | PRIMARY,rd_ns_title | PRIMARY | 4 | wikidatawiki.page.page_id |1 | Using where | +--+-+++--+-+-+---+--+--+ 5 rows in set (0.00 sec) I find the subquery a bit confusing, but it seems if we join page on pl_from = page_id, we should be using the primary index... Any idea what's going wrong there? Or what index hints we can use to fix it? Also, do you have an idea why i'm getting the bad query plan when running `explain` on the production DB, but the actual page that runs that query loads fine? TASK DETAIL https://phabricator.wikimedia.org/T254688 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: aaron, daniel Cc: daniel, Lydia_Pintscher, Ladsgroup, Addshore, Aklapper, Marostegui, Akuckartz, darthmon_wmde, WDoranWMF, holger.knust, EvanProdromou, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Agabi10, Scott_WUaS, Pchelolo, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T254688: SpecialWhatLinksHere::showIndirectLinks on wikidatawiki needs optimizing
daniel added a comment. In T254688#6395860 <https://phabricator.wikimedia.org/T254688#6395860>, @Lydia_Pintscher wrote: > Hard to tell without the context of when this is happening for users. Does anyone know? The query in question is generated by https://www.wikidata.org/wiki/Special:WhatLinksHere/Property:P248. That seems to work fine though, and returns nearly instantly. In T254688#6405204 <https://phabricator.wikimedia.org/T254688#6405204>, @Marostegui wrote: > So far I haven't seen anything being overloaded by this query, but it might in the future, who knows. > However, given the huge amount of rows this query has to scan, I doubt it will ever finish on time before being killed. So whatever uses it, might not get the expected data Since the link above works fine, it appears to me that the query is only "sometimes" problematic, due to a suboptimal query plan. For me locally, on a nearly empty database, the query plan looks like this: +--+-+++--+--+-+-+--+--+ | id | select_type | table | type | possible_keys| key | key_len | ref | rows | Extra| +--+-+++--+--+-+-+--+--+ |1 | PRIMARY | | ALL| NULL | NULL | NULL| NULL| 2| Using filesort | |1 | PRIMARY | page | eq_ref | PRIMARY | PRIMARY | 4 | temp_backlink_range.pl_from | 1| | |2 | DERIVED | pagelinks | ref| PRIMARY,pl_namespace | pl_namespace | 261 | const,const | 1| Using where; Using index | |2 | DERIVED | redirect | eq_ref | PRIMARY,rd_ns_title | PRIMARY | 4 | default.pagelinks.pl_from | 1| Using where | |2 | DERIVED | page | eq_ref | PRIMARY | PRIMARY | 4 | default.pagelinks.pl_from | 1| Using index | +--+-+++--+--+-+-+--+--+ I see only one "using filesort" there, and no "using temporary". But that may just be because there are no redirects to this page. But then, there are no redirects to Property:P248 on wikidata either... Any idea when and why the query plan becomes nasty, and what to do about it? TASK DETAIL https://phabricator.wikimedia.org/T254688 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: aaron, daniel Cc: daniel, Lydia_Pintscher, Ladsgroup, Addshore, Aklapper, Marostegui, Akuckartz, darthmon_wmde, WDoranWMF, holger.knust, EvanProdromou, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Agabi10, Scott_WUaS, Pchelolo, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T254688: SpecialWhatLinksHere::showIndirectLinks on wikidatawiki needs optimizing
daniel added subscribers: Lydia_Pintscher, daniel. daniel edited projects, added Platform Engineering; removed Platform Team Workboards (Clinic Duty Team). daniel added a comment. Back to the inbox for triage. This isn't actionable as it is. We'd probably have to design a new schema for representing the relevant info in the DB to make this work. Could be a "future initiative". @Lydia_Pintscher: how important is this for Wikidata? @Marostegui: how critical is this for DBAs? As a stop gap, we could just disable the feature on wikidata. TASK DETAIL https://phabricator.wikimedia.org/T254688 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: aaron, daniel Cc: daniel, Lydia_Pintscher, Ladsgroup, Addshore, Aklapper, Marostegui, Akuckartz, darthmon_wmde, WDoranWMF, holger.knust, EvanProdromou, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Agabi10, Scott_WUaS, Pchelolo, Wikidata-bugs, aude, Mbch331, Naike, eprodromou ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T257002: Internal error on Special:Contributions in Wikidata
daniel added a comment. might be related to T253289: Remove USE INDEX usertext_timestamp and other references from code <https://phabricator.wikimedia.org/T253289> TASK DETAIL https://phabricator.wikimedia.org/T257002 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: daniel, Bugreporter, jhsoby, Aklapper, darthmon_wmde, Nandana, Amorymeltzer, Lahi, Gq86, Lsherwinforone, GoranSMilovanovic, Jayprakash12345, QZanden, LawExplorer, Sethakill, _jensen, rosalieper, Scott_WUaS, Wong128hk, Wikidata-bugs, aude, 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] T249598: Wikibase schema updaters must not modify database directly
daniel added a comment. > The original core test still throws errors that seem related to Wikibase You mean this one? https://gerrit.wikimedia.org/r/c/mediawiki/core/+/475065 As I noted there: > The "dangerous" methods on DatabaseUpdater are no longer public, see Ie73e6143bb5cbce0dae705a7451fb49cf7e3abcd. > The structure test would need to be changed to prevent access to dangerous methods on the Database object. I'm not sure how exactly the "DB connection was already closed" issue is triggered, but the structure test as written no longer makes sense. TASK DETAIL https://phabricator.wikimedia.org/T249598 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Michael, Jdforrester-WMF, Aklapper, Krinkle, kchapman, Pablo-WMDE, Ladsgroup, alaa_wmde, Anomie, Addshore, WMDE-leszek, kostajh, daniel, Blissjay007, Oblanco79, Alter-paule, Beast1978, Un1tY, Hook696, Daryl-TTMG, RomaAmorRoma, E.S.A-Sheild, Iflorez, darthmon_wmde, Kent7301, Meekrab2012, joker88john, 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] T252091: RFC: Site-wide edit rate limiting with PoolCounter
daniel added a comment. For reference, Brad used PooLCounter to impose a limit on Special:Contributions recently, see https://gerrit.wikimedia.org/r/c/mediawiki/core/+/551909 TASK DETAIL https://phabricator.wikimedia.org/T252091 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: 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] T251452: Tests fails on ApiEditPageTest::testEditWhileReadOnly fails with PHP Fatal error on MacOS, php 7.4.1 if Wikibase/repo enabled
daniel edited projects, added Wikidata; removed Core Platform Team Workboards (Clinic Duty Team). daniel added a subscriber: Addshore. daniel added a comment. Untagging CPT, tagging #wikidata <https://phabricator.wikimedia.org/tag/wikidata/> . Pinging @Addshore to have a look. TASK DETAIL https://phabricator.wikimedia.org/T251452 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Peter.ovchyn, daniel Cc: Addshore, daniel, Peter.ovchyn, Aklapper, darthmon_wmde, DannyS712, Nandana, Jinoytommanjaly, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Jdforrester-WMF, Mbch331, Naike, eprodromou, Agabi10, Pchelolo ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T251457: LoadBalancer: Transaction spent [n] second(s) in writes, exceeding the limit of [n]
daniel added a comment. In T251457#6105089 <https://phabricator.wikimedia.org/T251457#6105089>, @Jdforrester-WMF wrote: > UBN patches, and particularly train-blocking UBN patches, should not wait for SWAT, but be deployed immediately (in line with https://wikitech.wikimedia.org/wiki/Deployments/Emergencies). One of these days I'll learn how to do that. I'm still scared of prod servers. TASK DETAIL https://phabricator.wikimedia.org/T251457 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Ladsgroup, Nikerabbit, Tgr, Agusbou2015, Pchelolo, daniel, DannyS712, Jdforrester-WMF, Krinkle, Marostegui, Liuxinyu970226, brennen, Bugreporter, LarsWirzenius, Hogue, Aklapper, Naike, Blissjay007, Oblanco79, Alter-paule, Beast1978, Un1tY, eprodromou, Hook696, Daryl-TTMG, RomaAmorRoma, E.S.A-Sheild, darthmon_wmde, Kent7301, Meekrab2012, joker88john, CucyNoiD, Nandana, NebulousIris, Banyek, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Rayssa-, Lahi, Gq86, Af420, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, WSH1906, Lewizho99, Maathavan, _jensen, rosalieper, Agabi10, Scott_WUaS, Jonas, Wikidata-bugs, aude, Dinoguy1000, Lydia_Pintscher, 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] T251457: LoadBalancer: Transaction spent [n] second(s) in writes, exceeding the limit of [n]
daniel added a comment. In T251457#6104041 <https://phabricator.wikimedia.org/T251457#6104041>, @LarsWirzenius wrote: > https://gerrit.wikimedia.org/r/593757 has been merged, but has it been deployed (I assume it will need to be backported to the 1.35.0-wmf.30 branch as well)? Train it held until it has been. Scheduled for SWAT https://wikitech.wikimedia.org/w/index.php?title=Deployments&type=revision&diff=1864961&oldid=1864936 TASK DETAIL https://phabricator.wikimedia.org/T251457 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Ladsgroup, Nikerabbit, Tgr, Agusbou2015, Pchelolo, daniel, DannyS712, Jdforrester-WMF, Krinkle, Marostegui, Liuxinyu970226, brennen, Bugreporter, LarsWirzenius, Hogue, Aklapper, Naike, Blissjay007, Oblanco79, Alter-paule, Beast1978, Un1tY, eprodromou, Hook696, Daryl-TTMG, RomaAmorRoma, E.S.A-Sheild, darthmon_wmde, Kent7301, Meekrab2012, joker88john, CucyNoiD, Nandana, NebulousIris, Banyek, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Rayssa-, Lahi, Gq86, Af420, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, WSH1906, Lewizho99, Maathavan, _jensen, rosalieper, Agabi10, Scott_WUaS, Jonas, Wikidata-bugs, aude, Dinoguy1000, Lydia_Pintscher, 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] T230833: wbsearchentities for lexemes returns 'und' match language on Test Wikidata
daniel added a comment. > Using IETF language tags seems like the most useful solution to me I dimly recall a similar discussion from years ago. IIRC, IETF is extensible, and we came up with a way to encode item IDs in language tages, something like `qid-36163` (by fortunate coincidence, "qid" lies within the range for private use tags, between "qaa" and "qtz"), or `und-x-wikidata-Q36163` (the "mis" code should not be used, according to BCP47). Isn't Wikibase using this kind of encoding somewhere already? TASK DETAIL https://phabricator.wikimedia.org/T230833 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: So9q, daniel, Addshore, Lydia_Pintscher, Nikki, LucasWerkmeister, darthmon_wmde, Nandana, Mringgaard, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T251457: LoadBalancer: Transaction spent [n] second(s) in writes, exceeding the limit of [n]
daniel added a comment. While I was chatting with @Krinkle on IRC, he found out that https://gerrit.wikimedia.org/r/c/mediawiki/core/+/582022 caused Database::lock() to be treated as a write operation now. This was not the case before, and indeed should not be the case. This means the error reported here is spurious, the transaction isn't actually spending a lot of time in writes. TASK DETAIL https://phabricator.wikimedia.org/T251457 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Tgr, Agusbou2015, Pchelolo, daniel, DannyS712, Jdforrester-WMF, Krinkle, Marostegui, Liuxinyu970226, brennen, Bugreporter, LarsWirzenius, Hogue, Aklapper, Naike, Blissjay007, Oblanco79, Alter-paule, Beast1978, Un1tY, eprodromou, Hook696, Daryl-TTMG, RomaAmorRoma, E.S.A-Sheild, darthmon_wmde, Kent7301, Meekrab2012, joker88john, CucyNoiD, Nandana, NebulousIris, Banyek, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Rayssa-, Lahi, Gq86, Af420, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, WSH1906, Lewizho99, Maathavan, _jensen, rosalieper, Agabi10, Scott_WUaS, Jonas, Wikidata-bugs, aude, Dinoguy1000, Lydia_Pintscher, 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] T251457: LoadBalancer: Transaction spent [n] second(s) in writes, exceeding the limit of [n]
daniel added a comment. In T251457#6099971 <https://phabricator.wikimedia.org/T251457#6099971>, @Tgr wrote: > MediaWiki automatically wraps the entire request in a transaction if it encounters a write which does not do its own transaction handling. So something unrelated to saving could have started the transaction, like AbuseFilter taking an action, or a session refresh (although I would expect either to show up in Logstash). That's true, but an automatic transaction would have been flushed before starting the explicit transaction for the revision creation, I think... My plan of action for now: - make database::lock() flush automatic transactions. - make database::lock() flush warn about explicit transactions (and fail tests) - make the Parser warn if an explicit transaction is in progress (and fail tests) I hope that this will trigger the condition that causes this timeout in production, by making tests fail. TASK DETAIL https://phabricator.wikimedia.org/T251457 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Tgr, Agusbou2015, Pchelolo, daniel, DannyS712, Jdforrester-WMF, Krinkle, Marostegui, Liuxinyu970226, brennen, Bugreporter, LarsWirzenius, Hogue, Aklapper, Naike, eprodromou, darthmon_wmde, Nandana, Banyek, Rayssa-, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Agabi10, Scott_WUaS, Jonas, Wikidata-bugs, aude, Dinoguy1000, Lydia_Pintscher, 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] T251457: LoadBalancer: Transaction spent [n] second(s) in writes, exceeding the limit of [n]
daniel added a comment. > I'm not entirely sure I understand it correctly, but PageEditStash::getAndWaitForStashValue uses ILoadBalancer::getAnyOpenConnection and by chance acquires a connection where a transaction was already open for edit? Yes. the question is, why is there a transaction open when EditPage::runPostMergeFilters is called? In my mind, that should not be the case. TASK DETAIL https://phabricator.wikimedia.org/T251457 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Agusbou2015, Pchelolo, daniel, DannyS712, Jdforrester-WMF, Krinkle, Marostegui, Liuxinyu970226, brennen, Bugreporter, LarsWirzenius, Hogue, Aklapper, Naike, eprodromou, darthmon_wmde, Nandana, Banyek, Rayssa-, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Agabi10, Scott_WUaS, Jonas, Wikidata-bugs, aude, Dinoguy1000, Lydia_Pintscher, 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] T251457: LoadBalancer: Transaction spent [n] second(s) in writes, exceeding the limit of [n]
daniel added a comment. @Pchelolo can you provide the rest of the stack trace? This is triggered via SpamBlacklistHooks, and I want to understand why that is being executed inside the DB transaction. TASK DETAIL https://phabricator.wikimedia.org/T251457 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Agusbou2015, Pchelolo, daniel, DannyS712, Jdforrester-WMF, Krinkle, Marostegui, Liuxinyu970226, brennen, Bugreporter, LarsWirzenius, Hogue, Aklapper, Naike, eprodromou, darthmon_wmde, Nandana, Banyek, Rayssa-, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Agabi10, Scott_WUaS, Jonas, Wikidata-bugs, aude, Dinoguy1000, Lydia_Pintscher, 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] T251457: LoadBalancer: Transaction spent [n] second(s) in writes, exceeding the limit of [n]
daniel added a comment. In T251457#6098793 <https://phabricator.wikimedia.org/T251457#6098793>, @Krinkle wrote: > @daniel How did it work before? What needed to change? What actually changed? I'm not aware of any changes in that area. TASK DETAIL https://phabricator.wikimedia.org/T251457 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Agusbou2015, Pchelolo, daniel, DannyS712, Jdforrester-WMF, Krinkle, Marostegui, Liuxinyu970226, brennen, Bugreporter, LarsWirzenius, Hogue, Aklapper, Naike, eprodromou, darthmon_wmde, Nandana, Banyek, Rayssa-, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Agabi10, Scott_WUaS, Jonas, Wikidata-bugs, aude, Dinoguy1000, Lydia_Pintscher, 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] T251457: LoadBalancer: Transaction spent [n] second(s) in writes, exceeding the limit of [n]
daniel added a comment. So, PageEditStash::parseAndCache() parses the page while holding the lock. PageEditStash->getAndWaitForStashValue() waits for that lock, and it apparently does so within the DB transaction that will be used to write the new revision. If parsing takes long, the process waiting for the lock may wait for long, and the transaction may time out. Solution: PageEditStash->getAndWaitForStashValue() should be called ouside the transaction. Don't know yet how hard or easy that would be. Thanks @Pchelolo for digging up that stacktrace. I really need to improve my Kibana-Fo TASK DETAIL https://phabricator.wikimedia.org/T251457 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Agusbou2015, Pchelolo, daniel, DannyS712, Jdforrester-WMF, Krinkle, Marostegui, Liuxinyu970226, brennen, Bugreporter, LarsWirzenius, Hogue, Aklapper, Naike, eprodromou, darthmon_wmde, Nandana, Banyek, Rayssa-, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Agabi10, Scott_WUaS, Jonas, Wikidata-bugs, aude, Dinoguy1000, Lydia_Pintscher, 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] T251457: LoadBalancer: Transaction spent [n] second(s) in writes, exceeding the limit of [n]
daniel added a comment. In T251457#6098675 <https://phabricator.wikimedia.org/T251457#6098675>, @Pchelolo wrote: > It's PageEditStash. See my comment above. Saw it and already edited my comment ;) TASK DETAIL https://phabricator.wikimedia.org/T251457 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Agusbou2015, Pchelolo, daniel, DannyS712, Jdforrester-WMF, Krinkle, Marostegui, Liuxinyu970226, brennen, Bugreporter, LarsWirzenius, Hogue, Aklapper, Naike, eprodromou, darthmon_wmde, Nandana, Banyek, Rayssa-, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Agabi10, Scott_WUaS, Jonas, Wikidata-bugs, aude, Dinoguy1000, Lydia_Pintscher, 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] T251457: LoadBalancer: Transaction spent [n] second(s) in writes, exceeding the limit of [n]
daniel added a comment. In T251457#6098402 <https://phabricator.wikimedia.org/T251457#6098402>, @Pchelolo wrote: > @daniel I don't think this is that lock showing up here. Reading the code, it seems like if that lock was taken, we should've seen a bunch more queries in this transaction, like some deletes, read from the archive table etc. Good point. So, other candidates are: - SqlBagOStuff::lock, which is called indirectly but a lot of different caching related things, including WANObjectCache. Which in turn is used by NameTableStore, but we should only be doing reads on that during normal operation, and not locking the database... I hope. - PageEditStash. Should only be read, not written to, while saving a new revision. TASK DETAIL https://phabricator.wikimedia.org/T251457 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Agusbou2015, Pchelolo, daniel, DannyS712, Jdforrester-WMF, Krinkle, Marostegui, Liuxinyu970226, brennen, Bugreporter, LarsWirzenius, Hogue, Aklapper, Naike, eprodromou, darthmon_wmde, Nandana, Banyek, Rayssa-, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Agabi10, Scott_WUaS, Jonas, Wikidata-bugs, aude, Dinoguy1000, Lydia_Pintscher, Mbch331, Rxy, Jay8g, Krenair ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T251457: LoadBalancer: Transaction spent [n] second(s) in writes, exceeding the limit of [n]
daniel added a comment. Interesting. RevisionStore::insertRevisionRowOn() does uses GET_LOCK when it detects the auto-increment value of the revision table to be out of sync. This was introduced as a fix for T202032: Duplicate ar_rev_id values in several wikis <https://phabricator.wikimedia.org/T202032>. I suppose multiple saves detecting this, and all attempting to acquire the same lock, can lead to a pile-up, causing some such requests to time out. The pile-up could perhaps be avoided by intropducing a randomized delay before trying to acquire the lock. But that may still cause the transaction to time out. The big question is - why does the auto-increment value get out of whack? Was there a master switch? As far as I know, the original cause of T202032 <https://phabricator.wikimedia.org/T202032> should no longer happen with recent versions of Maria... TASK DETAIL https://phabricator.wikimedia.org/T251457 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Pchelolo, daniel, DannyS712, Jdforrester-WMF, Krinkle, Marostegui, Liuxinyu970226, brennen, Bugreporter, LarsWirzenius, Hogue, Aklapper, Naike, Blissjay007, Oblanco79, Alter-paule, Beast1978, Un1tY, eprodromou, Hook696, Daryl-TTMG, RomaAmorRoma, E.S.A-Sheild, darthmon_wmde, Kent7301, Meekrab2012, joker88john, CucyNoiD, Nandana, NebulousIris, Banyek, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Rayssa-, Lahi, Gq86, Af420, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, WSH1906, Lewizho99, Maathavan, _jensen, rosalieper, Agabi10, Scott_WUaS, Jonas, Wikidata-bugs, aude, Dinoguy1000, Lydia_Pintscher, Mbch331, Rxy, Jay8g, Krenair ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T251457: LoadBalancer: Transaction spent [n] second(s) in writes, exceeding the limit of [n]
daniel added subscribers: DannyS712, daniel. daniel added a comment. Pinging patch author @DannyS712 TASK DETAIL https://phabricator.wikimedia.org/T251457 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: daniel, DannyS712, Jdforrester-WMF, Krinkle, Marostegui, Liuxinyu970226, brennen, Bugreporter, LarsWirzenius, Hogue, Aklapper, Naike, eprodromou, darthmon_wmde, Nandana, Banyek, Rayssa-, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Agabi10, Scott_WUaS, Pchelolo, Jonas, Wikidata-bugs, aude, Dinoguy1000, Lydia_Pintscher, Mbch331, Rxy, Jay8g, Krenair ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T251457: LoadBalancer: Transaction spent [n] second(s) in writes, exceeding the limit of [n]
daniel edited projects, added Core Platform Team Workboards (Clinic Duty Team); removed Core Platform Team. TASK DETAIL https://phabricator.wikimedia.org/T251457 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Liuxinyu970226, brennen, Bugreporter, LarsWirzenius, Hogue, Aklapper, Naike, eprodromou, darthmon_wmde, Nandana, Banyek, Rayssa-, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Agabi10, Scott_WUaS, Pchelolo, Jonas, Wikidata-bugs, aude, Dinoguy1000, Lydia_Pintscher, Jdforrester-WMF, Mbch331, Rxy, Jay8g, Krenair, WDoranWMF, holger.knust, EvanProdromou ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T157651: sql.php must not run LoadExtensionSchemaUpdates
daniel added a comment. In T157651#6075764 <https://phabricator.wikimedia.org/T157651#6075764>, @Krinkle wrote: > @daniel I noticed a patch that makes some methods inaccesible to extensions. Does that mean this structure test is no longer needed? Or are there some dangerous methods exposed still? See my comment on the patch: the structure test could still ensure that no dangerous methods are called on the Database object (rather than on DatabaseUpdater). The dangerous methods on DatabaseUpdater are no longer accessible to extensions, but they could still call Database::dropTable() directly. > Also, does the sql.php script now never run this hook? The hook call was removed from the constructor of DatabaseUpdater, and is now triggered from doUpdates(). I see no way for sql.php to trigger it. TASK DETAIL https://phabricator.wikimedia.org/T157651 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Demian, Jdforrester-WMF, kostajh, WMDE-leszek, Addshore, Anomie, alaa_wmde, daniel, Ladsgroup, Pablo-WMDE, kchapman, Krinkle, Catrope, Reception123, gerritbot, aaron, Aklapper, Tgr, Blissjay007, Oblanco79, Alter-paule, NavinRizwi, Beast1978, Un1tY, eprodromou, Hook696, Daryl-TTMG, RomaAmorRoma, E.S.A-Sheild, darthmon_wmde, Kent7301, Meekrab2012, joker88john, 94rain, CucyNoiD, Nandana, Lens0021, NebulousIris, jijiki, Gaboe420, Jony, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Imarlier, Lahi, Gq86, Af420, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, 45Jayjay1969, Jayprakash12345, Th3d3v1ls, Ramalepe, Liugev6, QZanden, EnricoCNC, LawExplorer, Vali.matei, WSH1906, Lewizho99, Maathavan, elukey, _jensen, rosalieper, Agabi10, Taiwania_Justo, Scott_WUaS, Pchelolo, SBisson, Wong128hk, Wikidata-bugs, aude, Dcljr, Bawolff, Dinoguy1000, Gryllida, jeblad, ArielGlenn, He7d3r, Mbch331, Rxy, Jay8g, akosiaris ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T157651: sql.php runs LoadExtensionSchemaUpdates
daniel added a comment. It seems like all essential patches are merged. Can this be closed now? TASK DETAIL https://phabricator.wikimedia.org/T157651 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Demian, Jdforrester-WMF, kostajh, WMDE-leszek, Addshore, Anomie, alaa_wmde, daniel, Ladsgroup, Pablo-WMDE, kchapman, Krinkle, Catrope, Reception123, gerritbot, aaron, Aklapper, Tgr, Blissjay007, Oblanco79, Alter-paule, NavinRizwi, Beast1978, Un1tY, eprodromou, Hook696, Daryl-TTMG, RomaAmorRoma, E.S.A-Sheild, darthmon_wmde, Kent7301, Meekrab2012, joker88john, 94rain, CucyNoiD, Nandana, Lens0021, NebulousIris, jijiki, Gaboe420, Jony, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Imarlier, Lahi, Gq86, Af420, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, 45Jayjay1969, Jayprakash12345, Th3d3v1ls, Ramalepe, Liugev6, QZanden, EnricoCNC, LawExplorer, Vali.matei, WSH1906, Lewizho99, Maathavan, elukey, _jensen, rosalieper, Agabi10, Taiwania_Justo, Scott_WUaS, Pchelolo, SBisson, Wong128hk, Wikidata-bugs, aude, Dcljr, Bawolff, Dinoguy1000, Gryllida, jeblad, ArielGlenn, He7d3r, Mbch331, Rxy, Jay8g, akosiaris ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T249598: Wikibase schema updaters must not modify database directly
daniel added a comment. In T249598#6073487 <https://phabricator.wikimedia.org/T249598#6073487>, @daniel wrote: > Oh wait, this patch also belongs here, right? > https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/507898 Actually, I think that patch is wrong. So, can we close this? TASK DETAIL https://phabricator.wikimedia.org/T249598 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Jdforrester-WMF, Aklapper, Krinkle, kchapman, Pablo-WMDE, Ladsgroup, alaa_wmde, Anomie, Addshore, WMDE-leszek, kostajh, daniel, Blissjay007, Oblanco79, Alter-paule, Beast1978, Un1tY, Hook696, Daryl-TTMG, RomaAmorRoma, E.S.A-Sheild, darthmon_wmde, Kent7301, Meekrab2012, joker88john, 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] T249598: Wikibase schema updaters must not modify database directly
daniel added a comment. Oh wait, this patch also belongs here, right? https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/507898 TASK DETAIL https://phabricator.wikimedia.org/T249598 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Jdforrester-WMF, Aklapper, Krinkle, kchapman, Pablo-WMDE, Ladsgroup, alaa_wmde, Anomie, Addshore, WMDE-leszek, kostajh, daniel, Blissjay007, Oblanco79, Alter-paule, Beast1978, Un1tY, Hook696, Daryl-TTMG, RomaAmorRoma, E.S.A-Sheild, darthmon_wmde, Kent7301, Meekrab2012, joker88john, 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] [Closed] T249603: DatabaseUpdater: protect methods for direct database modification
daniel closed this task as "Resolved". TASK DETAIL https://phabricator.wikimedia.org/T249603 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: RhinosF1, Tgr, Aklapper, aaron, gerritbot, Reception123, Catrope, Krinkle, kchapman, Pablo-WMDE, Ladsgroup, alaa_wmde, Anomie, Addshore, WMDE-leszek, kostajh, daniel, NavinRizwi, eprodromou, darthmon_wmde, MJL, Nandana, Jony, Hispano76, Lahi, Gq86, GoranSMilovanovic, Jayprakash12345, QZanden, LawExplorer, Vali.matei, _jensen, rosalieper, Agabi10, Taiwania_Justo, Scott_WUaS, Pchelolo, Wikidata-bugs, aude, Dcljr, Mbch331, Rxy ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Unblock] T157651: sql.php runs LoadExtensionSchemaUpdates
daniel closed subtask T249603: DatabaseUpdater: protect methods for direct database modification as "Resolved". TASK DETAIL https://phabricator.wikimedia.org/T157651 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Demian, Jdforrester-WMF, kostajh, WMDE-leszek, Addshore, Anomie, alaa_wmde, daniel, Ladsgroup, Pablo-WMDE, kchapman, Krinkle, Catrope, Reception123, gerritbot, aaron, Aklapper, Tgr, Blissjay007, Oblanco79, Alter-paule, NavinRizwi, Beast1978, Un1tY, eprodromou, Hook696, Daryl-TTMG, RomaAmorRoma, E.S.A-Sheild, darthmon_wmde, Kent7301, Meekrab2012, joker88john, 94rain, CucyNoiD, Nandana, Lens0021, NebulousIris, jijiki, Gaboe420, Jony, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Imarlier, Lahi, Gq86, Af420, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, 45Jayjay1969, Jayprakash12345, Th3d3v1ls, Ramalepe, Liugev6, QZanden, EnricoCNC, LawExplorer, Vali.matei, WSH1906, Lewizho99, Maathavan, elukey, _jensen, rosalieper, Agabi10, Taiwania_Justo, Scott_WUaS, Pchelolo, SBisson, Wong128hk, Wikidata-bugs, aude, Dcljr, Bawolff, Gryllida, jeblad, ArielGlenn, He7d3r, Mbch331, Rxy, Jay8g, akosiaris ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T249598: Wikibase schema updaters must not modify database directly
daniel added a comment. Looks like this is done, can the ticket be closed? TASK DETAIL https://phabricator.wikimedia.org/T249598 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Jdforrester-WMF, Aklapper, Krinkle, kchapman, Pablo-WMDE, Ladsgroup, alaa_wmde, Anomie, Addshore, WMDE-leszek, kostajh, daniel, Blissjay007, Oblanco79, Alter-paule, Beast1978, Un1tY, Hook696, Daryl-TTMG, RomaAmorRoma, E.S.A-Sheild, darthmon_wmde, Kent7301, Meekrab2012, joker88john, 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] [Unblock] T242717: Wikidata daily browser tests fails on Beta due to "Unable to store text to external storage"
daniel closed subtask T228088: BetaCluster: ExternalStoreException - Unable to store text to external storage as "Resolved". TASK DETAIL https://phabricator.wikimedia.org/T242717 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Krinkle, Etonkovidova, Aklapper, Addshore, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86, Bsandipan, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, zeljkofilipin, Mbch331, Rxy, Jay8g, Krenair ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T249603: DatabaseUpdater: protect methods for direct database modification
daniel updated the task description. TASK DETAIL https://phabricator.wikimedia.org/T249603 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: RhinosF1, Tgr, Aklapper, aaron, gerritbot, Reception123, Catrope, Krinkle, kchapman, Pablo-WMDE, Ladsgroup, alaa_wmde, Anomie, Addshore, WMDE-leszek, kostajh, daniel, Blissjay007, Oblanco79, Alter-paule, NavinRizwi, Beast1978, Un1tY, eprodromou, Hook696, Daryl-TTMG, RomaAmorRoma, E.S.A-Sheild, darthmon_wmde, MJL, Kent7301, Meekrab2012, joker88john, CucyNoiD, Nandana, NebulousIris, Gaboe420, Jony, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Hispano76, Lahi, Gq86, Af420, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Jayprakash12345, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, Vali.matei, WSH1906, Lewizho99, Maathavan, _jensen, rosalieper, Agabi10, Taiwania_Justo, Scott_WUaS, Pchelolo, Wikidata-bugs, aude, Dcljr, Mbch331, Rxy ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Claimed] T157651: sql.php runs LoadExtensionSchemaUpdates
daniel claimed this task. TASK DETAIL https://phabricator.wikimedia.org/T157651 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Demian, Jdforrester-WMF, kostajh, WMDE-leszek, Addshore, Anomie, alaa_wmde, daniel, Ladsgroup, Pablo-WMDE, kchapman, Krinkle, Catrope, Reception123, gerritbot, aaron, Aklapper, Tgr, Blissjay007, Oblanco79, Alter-paule, NavinRizwi, Beast1978, Un1tY, eprodromou, Hook696, Daryl-TTMG, RomaAmorRoma, E.S.A-Sheild, darthmon_wmde, Kent7301, Meekrab2012, joker88john, 94rain, CucyNoiD, Nandana, Lens0021, NebulousIris, jijiki, Gaboe420, Jony, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Imarlier, Lahi, Gq86, Af420, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, 45Jayjay1969, Jayprakash12345, Th3d3v1ls, Ramalepe, Liugev6, QZanden, EnricoCNC, LawExplorer, Vali.matei, WSH1906, Lewizho99, Maathavan, elukey, _jensen, rosalieper, Agabi10, Taiwania_Justo, Scott_WUaS, Pchelolo, SBisson, Wong128hk, Wikidata-bugs, aude, Dcljr, Bawolff, Gryllida, jeblad, ArielGlenn, He7d3r, Mbch331, Rxy, Jay8g, akosiaris ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T248459: Math extension randomly fails in gate-and-submit for Wikibase
daniel removed a project: Core Platform Team Workboards (Clinic Duty Team). daniel added a comment. Wikibase problem is apparently fixed, untagging CPT. TASK DETAIL https://phabricator.wikimedia.org/T248459 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: daniel, WDoranWMF, Pchelolo, WMDE-leszek, Jdforrester-WMF, Physikerwelt, Lucas_Werkmeister_WMDE, Addshore, Aklapper, Ladsgroup, Liuxinyu970226, darthmon_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, Maosef, QZanden, LawExplorer, Debenben, _jensen, rosalieper, Scott_WUaS, Jonas, Izno, Wikidata-bugs, aude, fredw, Pkra, Lydia_Pintscher, scfc, Mbch331, eprodromou, Agabi10 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T240083: "User::loadFromSession called before the end of Setup.php" (violation by Wikibase/ULS) [Story Points 5]
daniel added a comment. Note the the solution that was just merged is quite far from what is discussed in the task description. If further work is desired here, please re-open. TASK DETAIL https://phabricator.wikimedia.org/T240083 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Anomie, daniel Cc: Anomie, daniel, Ladsgroup, Addshore, Nikerabbit, Krinkle, Aklapper, eprodromou, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Agabi10, Taiwania_Justo, Scott_WUaS, Pchelolo, Wikidata-bugs, aude, Amire80, Arrbee, santhosh, KartikMistry, 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] [Closed] T240083: "User::loadFromSession called before the end of Setup.php" (violation by Wikibase/ULS) [Story Points 5]
daniel moved this task from Waiting for Review to Done on the Core Platform Team Workboards (Clinic Duty Team) board. daniel closed this task as "Resolved". TASK DETAIL https://phabricator.wikimedia.org/T240083 WORKBOARD https://phabricator.wikimedia.org/project/board/4149/ EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Anomie, daniel Cc: Anomie, daniel, Ladsgroup, Addshore, Nikerabbit, Krinkle, Aklapper, eprodromou, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Agabi10, Taiwania_Justo, Scott_WUaS, Pchelolo, Wikidata-bugs, aude, Amire80, Arrbee, santhosh, KartikMistry, 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] [Unblock] T157651: sql.php runs LoadExtensionSchemaUpdates
daniel closed subtask T249584: Call LoadExtensionSchemaUpdates later as "Resolved". TASK DETAIL https://phabricator.wikimedia.org/T157651 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Jdforrester-WMF, kostajh, WMDE-leszek, Addshore, Anomie, alaa_wmde, daniel, Ladsgroup, Pablo-WMDE, kchapman, Krinkle, Catrope, Reception123, gerritbot, aaron, Aklapper, Tgr, Oblanco79, Alter-paule, NavinRizwi, Beast1978, Un1tY, Demian, eprodromou, Hook696, Daryl-TTMG, RomaAmorRoma, E.S.A-Sheild, Iflorez, darthmon_wmde, Kent7301, Meekrab2012, joker88john, 94rain, CucyNoiD, Nandana, Lens0021, NebulousIris, jijiki, Gaboe420, Jony, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Imarlier, Lahi, Gq86, Af420, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, 45Jayjay1969, Jayprakash12345, Th3d3v1ls, Ramalepe, Liugev6, QZanden, Marostegui, EnricoCNC, LawExplorer, Vali.matei, WSH1906, Lewizho99, Minhnv-2809, Maathavan, elukey, _jensen, rosalieper, Agabi10, Taiwania_Justo, Scott_WUaS, Pchelolo, SBisson, Wong128hk, Wikidata-bugs, aude, Dcljr, Bawolff, Gryllida, jeblad, ArielGlenn, He7d3r, Mbch331, Rxy, Jay8g, Krenair, akosiaris ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Closed] T198557: Remove the ability to write pre-MCR fields, limit the ability to read pre-MCR fields to migration scripts
daniel closed this task as "Resolved". daniel added a comment. It's done, as far as I know TASK DETAIL https://phabricator.wikimedia.org/T198557 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Anomie, DannyS712, Jdforrester-WMF, BPirkle, Fjalapeno, CCicalese_WMF, Aklapper, daniel, darthmon_wmde, RhinosF1, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, JJMC89, _jensen, rosalieper, Agabi10, Scott_WUaS, 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] [Unblock] T198492: Create a maintenance script to drop rev_text_id and ar_text_id from the database.
daniel closed subtask T198557: Remove the ability to write pre-MCR fields, limit the ability to read pre-MCR fields to migration scripts as "Resolved". TASK DETAIL https://phabricator.wikimedia.org/T198492 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: tstarling, Aklapper, Anomie, Jdforrester-WMF, Tgr, daniel, darthmon_wmde, RhinosF1, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, JJMC89, _jensen, rosalieper, Agabi10, Scott_WUaS, 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] T205094: Investigate restructure SQL directory
daniel added a comment. Note: the above patch apparently missed on occurrence of dropTable() TASK DETAIL https://phabricator.wikimedia.org/T205094 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: daniel, Addshore, Aklapper, Matthias_Geisler_WMDE, Jonas, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, Jayprakash12345, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Izno, Wikidata-bugs, aude, Dinoguy1000, Lydia_Pintscher, Mbch331, Jay8g ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T157651: sql.php runs LoadExtensionSchemaUpdates
daniel added a subtask: T249584: Call LoadExtensionSchemaUpdates later. TASK DETAIL https://phabricator.wikimedia.org/T157651 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: kostajh, WMDE-leszek, Addshore, Anomie, alaa_wmde, daniel, Ladsgroup, Pablo-WMDE, kchapman, Krinkle, Catrope, Reception123, gerritbot, aaron, Aklapper, Tgr, Oblanco79, Alter-paule, NavinRizwi, Beast1978, Un1tY, Demian, eprodromou, Hook696, Daryl-TTMG, RomaAmorRoma, E.S.A-Sheild, Iflorez, darthmon_wmde, Kent7301, Meekrab2012, joker88john, 94rain, CucyNoiD, Nandana, Lens0021, NebulousIris, jijiki, Gaboe420, Jony, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Imarlier, Lahi, Gq86, Af420, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, 45Jayjay1969, Jayprakash12345, Th3d3v1ls, Ramalepe, Liugev6, QZanden, Marostegui, EnricoCNC, LawExplorer, Vali.matei, WSH1906, Lewizho99, Minhnv-2809, Maathavan, elukey, _jensen, rosalieper, Agabi10, Taiwania_Justo, Scott_WUaS, Pchelolo, SBisson, Wong128hk, Wikidata-bugs, aude, Dcljr, Bawolff, Gryllida, jeblad, ArielGlenn, He7d3r, Jdforrester-WMF, Mbch331, Rxy, Jay8g, Krenair, akosiaris ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Merged] T249599: DatabaseUpdater should not call hooks in the constructor
daniel closed this task as a duplicate of T249584: Call LoadExtensionSchemaUpdates later. TASK DETAIL https://phabricator.wikimedia.org/T249599 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Aklapper, aaron, gerritbot, Krinkle, Ladsgroup, Anomie, Addshore, daniel, Oblanco79, Alter-paule, Beast1978, Un1tY, eprodromou, Hook696, Daryl-TTMG, RomaAmorRoma, E.S.A-Sheild, darthmon_wmde, Kent7301, Meekrab2012, joker88john, CucyNoiD, Nandana, NebulousIris, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Af420, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Jayprakash12345, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, WSH1906, Lewizho99, Maathavan, _jensen, rosalieper, Agabi10, Scott_WUaS, Pchelolo, Wikidata-bugs, aude, Dcljr, Mbch331, Rxy ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Triaged] T249603: DatabaseUpdater: protect methods for direct database modification
daniel moved this task from Inbox to Ready on the Core Platform Team Workboards (Clinic Duty Team) board. daniel triaged this task as "High" priority. TASK DETAIL https://phabricator.wikimedia.org/T249603 WORKBOARD https://phabricator.wikimedia.org/project/board/4149/ EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: RhinosF1, Tgr, Aklapper, aaron, gerritbot, Reception123, Catrope, Krinkle, kchapman, Pablo-WMDE, Ladsgroup, alaa_wmde, Anomie, Addshore, WMDE-leszek, kostajh, daniel, Oblanco79, Alter-paule, NavinRizwi, Beast1978, Un1tY, eprodromou, Hook696, Daryl-TTMG, RomaAmorRoma, E.S.A-Sheild, darthmon_wmde, MJL, Kent7301, Meekrab2012, joker88john, CucyNoiD, Nandana, NebulousIris, Gaboe420, Jony, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Hispano76, Lahi, Gq86, Af420, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Jayprakash12345, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, Vali.matei, WSH1906, Lewizho99, Maathavan, _jensen, rosalieper, Agabi10, Taiwania_Justo, Scott_WUaS, Pchelolo, Wikidata-bugs, aude, Dcljr, Mbch331, Rxy ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T249598: Wikibase schema updaters must not modify database directly
daniel added a parent task: T249603: DatabaseUpdater: protect methods for direct database modification . TASK DETAIL https://phabricator.wikimedia.org/T249598 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Aklapper, Krinkle, kchapman, Pablo-WMDE, Ladsgroup, alaa_wmde, Anomie, Addshore, WMDE-leszek, kostajh, daniel, Oblanco79, Alter-paule, Beast1978, Un1tY, Hook696, Daryl-TTMG, RomaAmorRoma, E.S.A-Sheild, darthmon_wmde, Kent7301, Meekrab2012, joker88john, 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] [Updated] T249603: DatabaseUpdater: protect methods for direct database modification
daniel added a subtask: T249598: Wikibase schema updaters must not modify database directly. TASK DETAIL https://phabricator.wikimedia.org/T249603 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: RhinosF1, Tgr, Aklapper, aaron, gerritbot, Reception123, Catrope, Krinkle, kchapman, Pablo-WMDE, Ladsgroup, alaa_wmde, Anomie, Addshore, WMDE-leszek, kostajh, daniel, NavinRizwi, eprodromou, darthmon_wmde, MJL, Nandana, Jony, Hispano76, Lahi, Gq86, GoranSMilovanovic, Jayprakash12345, QZanden, LawExplorer, Vali.matei, _jensen, rosalieper, Agabi10, Taiwania_Justo, Scott_WUaS, Pchelolo, Wikidata-bugs, aude, Dcljr, Mbch331, Rxy ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
