[04:22:06] TIL that Phan can detect bad values being added to a typed array. https://phan.github.io/demo/?code=%3C%3Fphp%0Aclass+Foo+%7B%0A++++%2F**+%40var+string%5B%5D+*%2F%0A++++private+%24x+%3D+%5B%5D%3B%0A++++%0A++++public+function+add%28%24y+%3D+null%29+%7B%0A++++++++%24this-%3Ex%5B%5D+%3D+%24y%3B%0A++++%7D%0A%7D%0A%28+new+Foo+%29-%3Eadd%283%29%3B%0A%28+new+Foo+%29-%3Eadd%28%29%3B [04:22:42] This can help catch issues where eg you call a getter that returns a nullable string and forget to check for null before adding it to an array [04:23:14] That is (was?) one the reasons I sometimes favour throwing exceptions to force callers to handle it. [04:32:23] "Phan did not detect any errors. [04:52:38] Hmm I must've broken the example in the last change before sharing. It worked a minute ago. I'll retrace my steps. [06:28:19] OK. Yeah, apparently it doesn't work if the intermediary sig is untyped yet nullable. http://gg.gg/17xw9o [10:26:06] ooh, I didn’t know about phan in browser, that’s also useful [10:26:07] thanks! [15:26:21] Amir1: pmiazga: I rebased the OATHAuth stack so that the already approved DB builder patches can be merged now. looking at the comments on the remaining patches next [15:27:06] awesome [15:32:20] I think there is a value for deprecated config [15:32:22] let me check [15:33:47] nope [15:33:49] https://www.mediawiki.org/wiki/Manual:Extension_registration#Configs_(Your_extension/skins_settings) [15:43:24] Heyo, anyone knows why we can't tags ID from the API? https://en.wikipedia.org/w/api.php?action=help&modules=query%2Btags [15:44:54] For me, it means adding a JOIN to my query to "change_tag" table to check equality with "ctd_name" column... [15:45:44] Not a real problem, but still don't understand why we can't get ID from the API [15:46:01] I assume the tag IDs are considered internal implementation details that most users shouldn’t care about [15:46:12] if you’re working on the database level, joining against change_tag_def is the correct solution imho [15:46:21] Even query=logevents gives IDs with the title :-( [15:46:51] Alright, don't have many choices anyway [15:47:01] yeah but log IDs are actually accessible too [15:47:04] I am mixing API calls/databases queries [15:47:15] you can go to https://www.wikidata.org/wiki/Special:Log and get links with logid in the URL [15:47:24] tag IDs are never exposed in index.php as far as I’m aware [15:47:33] so they’re more internal in that way [15:47:39] :-( [15:48:21] (there’s also T215121 for actor IDs, which will probably never happen either tbh) [15:48:22] T215121: Expose actor IDs via the API - https://phabricator.wikimedia.org/T215121 [15:49:23] Funny that the filter is even using the name of the tag https://fr.wikipedia.org/w/index.php?title=Sp%C3%A9cial:Modifications_r%C3%A9centes&tagfilter=visualeditor [15:49:44] I will manifest for T215121! :D [15:52:42] yes, the tag name is the real identifier of the tag in a way [15:52:55] and the numeric ID just an artifact of how it’s stored in the database (normalized, since a few years ago) [15:54:11] Wait, does it mean that it is indexed [15:54:27] what do you mean? [15:55:23] +------------------+---------------------+------+-----+---------+-------+ [15:55:23] | Field            | Type                | Null | Key | Default | Extra | [15:55:24] +------------------+---------------------+------+-----+---------+-------+ [15:55:24] | ctd_id           | int(10) unsigned    | NO   |     | 0       |       | [15:55:25] | ctd_name         | varbinary(255)      | NO   |     | NULL    |       | [15:55:25] | ctd_user_defined | tinyint(1)          | NO   |     | NULL    |       | [15:55:26] | ctd_count        | bigint(20) unsigned | NO   |     | 0       |       | [15:55:26] +------------------+---------------------+------+-----+---------+-------+ [15:55:30] Sadge [15:55:43] But I think I can't get the indexes anyway, it is hidden I think? [15:56:10] the toolforge replicas don’t show you the indexes, yeah [15:56:21] (╯°□°)╯︵ ┻━┻ [15:56:40] is this what you’re looking for? https://gerrit.wikimedia.org/g/mediawiki/core/+/8cae398398/maintenance/tables-generated.sql#240 [15:57:00] UNIQUE INDEX ctd_name (ctd_name)! [15:57:03] Happy Lofhi. [15:57:07] Thanks [15:57:08] yay ^^ [15:58:53] oh no [15:59:12] Ah, nothing, mea culpa, it is case sensitive [15:59:38] Not uppercased by MediaWiki and stored in lowercases [15:59:47] yup [16:00:52] Now I need to work on dynamical pooling to the linguistic versions of Wikipedia db without really pooling since it is forbidden [16:00:54] also notice the difference between the identifier name and the displayed name [16:00:58] (columns 1 and 2 on https://en.wikipedia.org/wiki/Special:Tags) [16:01:10] be sure to look for column 1 :) [16:01:15] Traps everwhere [16:02:05] Do you have the time to read the logs of #wikimedia-cloud? I was there some hours ago and described the global context, I am still open to POV [16:02:32] I saw there were a lot of messages that someone was already responding to and mostly skimmed them tbh ^^ [16:02:35] but maybe I’ll check again later [16:02:46] Okidokie! [17:30:57] not sure if this is the right room, but does anyone know if you can get a php shell inside the k8s jobrunners? One of our jobs that compares the sql db to the elastic db's suddenly started finding ~400 errors/s, instead of >1. I suspect network, but it's hard to verify externally [17:31:01] re: https://grafana-rw.wikimedia.org/d/JLK3I_siz/elasticsearch-indexing?from=now-2d&orgId=1&to=now&viewPanel=35 [17:35:55] maybe try @wikimedia-cloud too [17:35:59] #wikimedia-cloud [17:47:36] ebernhardson: https://wikitech.wikimedia.org/wiki/MediaWiki_On_Kubernetes#MediaWiki_REPL [17:51:04] taavi: oh nice! somehow i missed that part. thanks. Hopefully the debug instance and jobrunners have same config