[12:29:08] dr0ptp4kt: Since you asked yesterday, it looks like TemplateStyles is functional on Beta Labs now (and probably has been for around 8 hours). [12:30:08] anomie: thanks! i happened to see your message while working on annual reviews. what a pleasant surprise! [14:17:40] What triggers a Wikidata extension build? Does someone poke something manually? [14:35:05] anomie: a cron job on a daily basis iirc. But aude would be able to trigger a Wikidata build [14:38:20] hashar: Looking at the git log, it doesn't seem to actually happen daily. [14:43:54] so maybe that is handled manually [15:56:22] anomie: How hard do you think it would be to implement some sort of recursion detection in Scribunto? [15:56:31] (ideally one we could surface back to the user) [15:57:15] Rephrase: we have detection...how could we get that back to users? [15:57:34] Within Lua, or Lua calling PHP calling Lua etc? [15:57:57] eg: [WUFUIgpAADsAACESLm4AAACI] /wiki/File:Schnorr_von_Carolsfeld_Bibel_in_Bildern_1860_197.png ErrorException from line 329 of /srv/mediawiki/php-1.30.0-wmf.4/extensions/Scribunto/engines/LuaSandbox/Engine.php: PHP Warning: LuaSandboxFunction::call(): recursion detected [15:58:53] We get a lot of those in logstash, but it's all because of userland stuff. They can't see the errors. [15:58:54] Ah, that's not call recursion, that's data structure recursion. I don't //think// it's possible to trigger that from on-wiki. [15:59:42] If it's not possible to catch that and bubble it back up to the user, I wonder if we could dump/sanitize the data and get it to communities to help them fix stuff? [16:01:29] RainbowSprinkles: Last time I looked into one of these log messages was in T166348. [16:01:29] T166348: Scribunto_LuaSandboxInterpreter::callFunction: LuaSandboxFunction::call returned false - https://phabricator.wikimedia.org/T166348 [16:02:06] * RainbowSprinkles nods [16:02:11] That's exactly what I'm seeing [16:03:15] I imagine it's probably a pretty small number of modules causing most of the errors. [16:03:36] I wonder if we could get the module name in the debug output. That would help the *most* [16:04:15] I don't see any reason to think it's a module at all. Unfortunately I have no idea what it actually is. I'll submit a patch to add some debug logging in wmf.5 and we can see what we get. [16:04:50] What's the name of the standard "random debug junk" log channel? [16:05:36] Ummm.... [16:07:15] AdHocDebug [16:16:14] RainbowSprinkles: https://gerrit.wikimedia.org/r/358988 [16:33:57] RainbowSprinkles: Hmm. Maybe we shouldn't deploy that, when I try it locally it looks like Monolog doesn't handle recursive data structures sanely at all. [16:35:59] Dump to json! [16:36:13] That's basically the answer to everything these days right? [16:36:16] Hehe [16:37:12] json_encode() just returns null, no help there. debug_zval_dump() looks promising. [16:37:35] Oh, wait, never mind. That doesn't return a string either. [16:43:56] var_export()? [16:45:33] Chokes. I'm just going to use serialize(), then I can copy-paste it locally. [16:45:34] https://gerrit.wikimedia.org/r/358993 [16:53:48] +2 [17:23:52] hey, so I tested my fix to https://phabricator.wikimedia.org/T166335 in vagrant and can't replicate the error I got in beta [17:24:12] when that fix got deployed to beta, it threw 500s anytime someone accessed a Config:Dashiki: page [17:25:08] my next step was going to be merging changes so they get deployed to beta and "guess and check" what I could possibly add to the config to make it work [17:25:15] is that frowned upon? Anyone have better ideas? [17:31:26] milimetric: Have you read ? It's very handy when you can't reproduce in mediawiki-vagrant or the like. [17:32:23] I had not. But isn't this what beta is for? [17:32:36] oh, you're saying you can apply this idea to beta too [17:33:53] I'm actually not sure whether it works in Beta or not. [21:21:08] TimStarling: Okay if I roll out https://gerrit.wikimedia.org/r/#/c/351767/ later?