[00:06:48] (PS1) Awight: function signature glitch [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/160569 [00:14:22] (PS9) Awight: WIP Standalone framework [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/139452 [00:14:41] (CR) jenkins-bot: [V: -1] WIP Standalone framework [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/139452 (owner: Awight) [00:18:30] (CR) Ejegg: [C: 2] class-ify CurrencyRates [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/160566 (owner: Awight) [00:18:46] (Merged) jenkins-bot: class-ify CurrencyRates [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/160566 (owner: Awight) [00:19:07] (CR) Ejegg: [C: 2] "Thank you for fixing my goof!" [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/160569 (owner: Awight) [00:19:35] (Merged) jenkins-bot: function signature glitch [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/160569 (owner: Awight) [01:22:41] (PS10) Awight: WIP Standalone framework [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/139452 [01:23:22] (CR) jenkins-bot: [V: -1] WIP Standalone framework [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/139452 (owner: Awight) [01:36:24] (PS11) Awight: Backport Standalone framework [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/139452 [01:39:11] (PS4) Awight: new recurring charge API [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/139476 [18:05:59] 11:07 <+icinga-wm> PROBLEM - check_apache2 on payments1004 is CRITICAL: PROCS CRITICAL: 0 processes with command name apache2 [18:06:20] not sure enough if it's important or not [18:08:11] alright. nvm < Jeff_Green> package update restarted apache [18:09:04] mutante: I'm marking all the payments* tests down for maintenance in icinga, hopefully that will make it shut up [18:10:06] Jeff_Green: thanks! it was just standing out between the flood of icinga stuff currently coming in from codfw that we can ignore [18:10:16] ha [18:10:18] ideally they would have scheduled that too :) [18:10:35] well last time I used the scheduling feature it didn't seem to help [18:10:47] actually, it already recovered, so don't worry :) [18:10:57] i gotta do more [18:11:05] there are different ways to do it [18:11:13] you can either "disabled notifications" [18:11:31] or you can "acknowledge" but then it only lasts until the next state change [18:11:46] or you can used scheduled downtime.. that _should_ also disable notifications in that time [18:11:55] that's what I'm trying [18:13:05] hmm, don't worry about it, we also see the recoveries [18:13:10] that's ok [18:13:13] yeah [18:54:21] centralnotice banner dismissal broken? https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Banner_keeps_reappearing [18:54:38] ut-oh! I'll look into that [19:04:38] Dang, looks like $.cookie isn't picking up the values of some cookies. Trying to understand that [19:08:24] thanks ejegg [19:08:38] greg-g, ^^ we might need to SWAT that one as well :P [19:10:22] ejegg: let me know (ping me) when you're ready with a fix for that. [19:11:32] ok, will do. It may have something to do with the cookie domain being .wikipedia.org rather than the full en.wikipedia.org, but it's hard to see why this would have just come up now. [19:12:09] Yesterday's deployment just swapped out the jquery.json dependency for the native json shim [19:14:59] eep payments down? [19:15:17] who, it don't rain but it pours! [19:15:23] *whoa [19:15:49] back up [19:16:41] whew [19:45:24] Eloquence, greg-g: the minified version of the centralNotice js is still coming back in some browsers as the previous version with the $.toJSON calls, though the dependencies seem to have been updated - pulling in the json shim and NOT jquery.json [19:45:51] I thought the caching of resource + dependencies were linked? [19:46:09] ^^ Krinkle may be able to help [19:46:33] OK, thank you, I'll ask Krinkle [19:49:17] How about dismissing a notice for all wikis, is that feature supposed to work? (It doesn't.) [19:49:48] Any JS errors? [19:51:31] Is that a "yes"? :) [19:53:22] Yeah, it's still supposed to work [19:53:45] Looks like it's still making all the right calls to SPecial:HideBanners, and getting cookies that lok right [19:54:06] ejegg: .wikipedia.org should work fine to cover *.wikipedia.org [19:54:35] ejegg: Yep, indeed. Resource manifests are hashed and invalidated accordingly [19:54:53] ejegg: Can you point me to the relevant source code? It may be circumventing ResourceLoader somehow. [19:56:17] Krinkle: here's the change we just deployed: https://gerrit.wikimedia.org/r/#/c/160466/ [19:57:58] CN does load some mixins via other means, but the bannerController and its dependencies are in the usual $wgResourceModules [20:00:49] ejegg: OK. Looks good [20:01:33] Though jQuery.JSON doesn't exist, it's jquery.json (package name; lowercase) or jQuery JSON (title), or jQuery.toJSON (js identifier) - but details [20:01:37] How do I reproduce the error? [20:01:39] ejegg: [20:02:10] Could it have to do with which cache server you hit? [20:02:39] I couldn't reproduce locally, but via crossborwsertesting.com some virtual machines were getting the mismatch [20:03:37] XP SP3-FF28, for example [20:06:21] ejegg: What's the request url providing the bannerController js script [20:06:29] does it contain bits, load.php and &version= [20:06:33] does it contain only= ? [20:06:47] let me get that, one sec [20:06:57] definitely load.php from bits [20:11:57] sorry, one more minute [20:38:44] Krinkle: sorry that took so long - it was http://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=ext.centralNotice.bannerController|ext.centralauth.centralautologin|ext.uls.init%2Cinterface%2Cpreferences%2Cwebfonts|ext.visualEditor.viewPageTarget.init|jquery.accessKeyLabel%2CbyteLength%2Cclient%2Ccookie%2CmwExtension%2CtabIndex%2Cthrottle-debounce%2Ctipsy|mediawiki.Title%2CUri%2Capi%2Ccldr%2CjqueryMsg%2Clanguage%2Cnotify%2Cus [20:43:10] got cut off, can you paste the end ? [20:43:43] last few params were: &skin=vector&version=20140915T182804Z&* [20:46:50] http://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=ext.centralNotice.bannerController| [20:46:53] ext.centralauth.centralautologin|ext.uls.init%2Cinterface%2Cpreferences%2Cwebfonts|ext.visualEditor.viewPageTarget.init| [20:46:56] jquery.accessKeyLabel%2CbyteLength%2Cclient%2Ccookie%2CmwExtension%2CtabIndex%2Cthrottle-debounce%2Ctipsy| [20:46:59] mediawiki.Title%2CUri%2Capi%2Ccldr%2CjqueryMsg%2Clanguage%2Cnotify%2Cuser%2Cutil|mediawiki.language.data%2Cinit| [20:47:02] mediawiki.legacy.ajax%2Cwikibits|mediawiki.libs.pluralruleparser|mediawiki.page.startup|mmv.base%2Chead| [20:47:05] skins.vector.js&skin=vector&version=20140915T182804Z&* [20:52:24] Krinkle: marktraceur mentioned it might be remedied by touching those two files again and re-syncing? [20:52:42] ejegg: Yeah [20:52:59] Sounds like a race condition in deployment to bits apaches and html apaches basically [20:53:19] Shouldn't be possible with the latest version of ResourceLoader as of a few months back [20:53:44] ejegg: Requesting it without the version= parameter or when appending &garbage123 [20:53:50] then it returns the correct script [20:53:58] so it definitely synced properly and there's no lower level cache hiding it [20:54:06] it's just in Varnish [20:54:27] A client requested the new version from a web page to Varnish before the apache behind that varnish had the new code [20:54:40] so the old code got re-cached under a new version url in Varnish [20:55:13] Touch bannerController.js and sync-file [20:55:17] would touching and re-syncing do anything to fix varnish serving the wrong version? [20:55:23] it'll propagate via startup module manifest in 5 min globally [20:55:27] OK, will do [20:55:33] Yes, it will bump the file mtime [20:55:37] and thus invalidate the previous url [21:20:55] OK, looks like that fixed it. Thanks very much for the explanation, Krinkle! [21:21:02] yw :) [21:23:39] hey tech - nudge on the PCR and PD stuff? :) [21:33:16] ejegg: K4-713 and i are headed to standup :) [21:33:29] ok, me too [23:15:50] i almost feel like we need a business capability or goal that is "prevent human error" [23:29:53] hey K4-713 do we need this for worldpay? https://wikimedia.mingle.thoughtworks.com/projects/online_fundraiser/cards/1590 [23:30:43] Errrr... [23:32:01] atgo: What does "accounts" mean next to "settle" and a timezone? [23:32:20] i haven't a clue [23:32:23] Rad. [23:32:24] Okay. [23:32:25] this was.. a while ago [23:32:30] dangit. [23:32:41] all i know is that DST != UTC [23:32:46] sometimes [23:32:51] So, this won't be an issue on payments, because we send our own idea of what time it is. [23:33:01] That's always the same. But. [23:33:09] aHA [23:33:13] this is from a mwalker email [23:33:21] If the reconciliation files don't correct for it, and they come in that way, those will be somewhat whack.