[00:00:36] Fundraising Sprint Testing on Production, Fundraising Sprint Unbreaking Now, Fundraising-Backlog, FR-2016-17-Q2-Campaign-Support, Patch-For-Review: Add time zone data back into Silverpop export file - https://phabricator.wikimedia.org/T148578#2761895 (CCogdill_WMF) Awesome, thanks @Ejegg! Can... [00:01:14] Fundraising Sprint Testing on Production, Fundraising Sprint Unbreaking Now, Fundraising-Backlog, FR-2016-17-Q2-Campaign-Support, Patch-For-Review: Add time zone data back into Silverpop export file - https://phabricator.wikimedia.org/T148578#2761896 (Ejegg) Sure thing @CCogdill_WMF [00:06:25] DId everyone else just get a flurry of failmail or was mine delayed? [00:06:38] yep i also saw them [00:06:57] looks like some lock contention [00:07:25] it's odd because under www-data there are no real queries running [00:07:29] a simple insert is all [00:08:01] nope ejegg's address update is stil running [00:08:24] sounds like a likely culprit [00:08:40] * cwd pretends to know what's going on [00:09:32] oops, I guess I should disable the recurring consumer too [00:10:53] I'm attempting to kill the query - I think there is a problem with it - ie. I think the postal_code field in the temp table might be int [00:10:57] not varchar [00:11:17] eileen1: oh shoot! [00:11:36] guess I need explicit table creation [00:11:53] yeah - I think the left will likely always be int [00:12:15] ejegg: semi interesting, i am getting "require is not a function" from https://github.com/wikimedia/mediawiki-extensions-CentralNotice/blob/261d61c75566ad62c21a4b7edefb37bebe2bf0d1/resources/subscribing/ext.centralNotice.geoIP.js#L127 [00:12:35] ahh, ok, just because it's digits, huh [00:12:35] yep [00:12:41] i'm not sure why yet but i notice require is not explicitly included in this context so it seems like a race condition [00:13:01] it is a thing that causes a banner to silently not show up [00:13:09] cwd we might be able to take that function arg out [00:13:21] there was a change to core that should make it not necessary [00:13:48] !log kill recurring global collect job for now (while query dies on server) [00:13:53] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log [00:13:55] and leaves the window.require function when debug=true [00:14:08] but it should still be defined right? [00:14:59] i don't understand why passing it there makes a difference :S [00:15:41] is that also a race condition but only in debug mode? [00:19:19] ok - that query is finally fully gone [00:20:09] !log enable recurring global collect job - query now dead, 26 contributions run but not in civi [00:20:15] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log [00:22:31] (PS1) Ejegg: Explicitly create table, break up updates [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/319256 (https://phabricator.wikimedia.org/T148578) [00:23:07] (PS2) Ejegg: Explicitly create table, break up updates [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/319256 (https://phabricator.wikimedia.org/T148578) [00:23:27] eileen1: maybe that will work ^^^ [00:23:49] cwd adding that argument was a totally undocumented hack [00:24:18] so i'm not too surprised if they took it out of the callback [00:24:32] leaving the undefined variable masking window.require [00:24:47] ejegg: looks good - I'll just test locally [00:24:58] heh, i should too [00:25:38] eileen1: oops, that exploded [00:25:48] ejegg: you still need the id index [00:25:53] for the second query [00:26:42] (PS3) Ejegg: Explicitly create table, break up updates [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/319256 (https://phabricator.wikimedia.org/T148578) [00:26:59] eileen1: oh, the PRIMARY KEY isn't enough? [00:27:46] sorry I missed that [00:28:22] k, PS3 ran fine for me. looking at the data [00:28:46] ejegg: sorry i know you are busy but whenever you have time, what is the point of passing require there? would it somehow be in scope for the calling code but not that function? [00:30:04] eileen1: yeah, looks fine [00:30:46] cwd I have no idea why, I just noticed the callback was getting it passed as an argument when I was trying to fix the initial breakage [00:30:57] I'll undo that... [00:31:48] ejegg: just running it through [00:31:58] oh ok, just trying to understand. no idea if that's what is giving me the error [00:33:19] because frex i get the error whether or not debug=true [00:34:02] (CR) Eileen: [C: 2] "Yep, that should do it. Also, it keeps the query away from our address table for longer" [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/319256 (https://phabricator.wikimedia.org/T148578) (owner: Ejegg) [00:35:39] (PS1) Ejegg: Undo 'require' debug mode hack [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/319259 [00:36:10] cwd ohh, dang, I wonder if that's happening for folks on production! [00:36:44] hey all — I’m a little concerned that I’m running a query showing we’ve only processed $4.43 in donations in the last hour… [00:37:16] (Merged) jenkins-bot: Explicitly create table, break up updates [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/319256 (https://phabricator.wikimedia.org/T148578) (owner: Ejegg) [00:37:19] that seems odd considering I sent 200k emails out 7 hours ago that should still be getting donations. is something off? [00:37:19] ccogdill: we've had the import job off while we run the updates to geocode the addresses [00:37:26] oh geez [00:37:26] okay [00:37:35] got really scared for my emails :D [00:37:36] We'll be turning it back on shortly! [00:37:38] thanks! [00:38:33] ejegg: the new version is merged now [00:38:36] (PS1) Ejegg: Merge branch 'master' into deployment [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/319261 [00:38:43] (CR) Ejegg: [C: 2] Merge branch 'master' into deployment [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/319261 (owner: Ejegg) [00:41:33] * ejegg waits for zuul to merge the merge [00:41:55] ejegg: anything is possible! whatever the cause it's not that require arg, i still get the error and no banner. i will track it down [00:42:28] oh huh [00:42:39] i have updated composer and submodules everywhere, but it sure seems like require is not loaded when the geoip lookup fires [00:43:07] weird [00:43:42] if i comment out the backgroundgeoip config, i get a banner and no errors [00:44:07] I mean, if that callback's not getting it passed in any more, then the function argument will mask window.require with undefined [00:44:25] can you see if window.require is still a thing at that point? [00:45:28] i am really rusty, but it's not defined when the page is finished loading [00:45:39] which seems weird, like it's not getting defined at all [00:47:09] cwd if you look at mediawiki.js, is this change applied? https://gerrit.wikimedia.org/r/#/c/313636/2/resources/src/mediawiki/mediawiki.js [00:47:34] in chrome dev tools, i go to sources and change something, how do i tell it to reload the local copy of the site? [00:47:39] (Merged) jenkins-bot: Merge branch 'master' into deployment [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/319261 (owner: Ejegg) [00:47:53] cwd uhhh [00:47:58] iono [00:48:52] is that not a thing? [00:48:56] !log updated CiviCRM from 38a6c26e65e1b91864ccfc730b32d1e0253df5ff to 954bab421fa3435c5dd1a80f59f657407764b620 [00:49:01] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log [00:49:09] ah ha that change is not applied [00:49:11] i'm still using crufty old firebug for the most part [00:49:50] heh yeah i haven't done any js debugging since i got lazy and started using chrome [00:51:46] yikes i did not realize my core checkout was this old [00:53:57] ejegg: I see you have pushed out the patch - have you tried re-running? [00:54:41] doing it now [00:56:09] ok, running [01:00:41] wanna bet on how long it takes :-) [01:00:58] oh it's finished [01:03:12] really? odd, not seeing the done line in nohup.out [01:04:34] no it hasn't [01:04:37] eileen1: yeah, ps -ef | grep drush shows it still going [01:04:44] it just didn't show in show process list [01:04:45] ooh, also a couple of merge jobs! [01:05:11] dang, and the ingenico audit parser too. [01:05:38] ejegg: yeah I had reneabled that merge - thinking it was finished - disabled again now [01:06:11] !log disabled ingenico audit parser [01:06:16] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log [01:06:59] ejegg: ok sorry all that flailing was just my out of date core [01:07:11] cwd ah, no worries [01:07:19] but, i did see another intersting thing [01:07:28] wrt not showing banners [01:07:41] I think we do need https://gerrit.wikimedia.org/r/319259 though [01:07:50] cwd what's that? [01:08:09] eileen1: this ran in 6 minutes on staging :S [01:08:21] well the first time i loaded the page ublock origin (ad blocker) blocked the freegeoip site which caused the banner to not show [01:08:54] it's up close to 10 now - not so much more … yet [01:09:12] oh? [01:09:27] but it is one of these learn-y adblockers so i'm having trouble reproducing [01:09:30] has it finished now? [01:09:35] cwd hmm, would be nice to have a soft failure mode then [01:09:38] no [01:09:46] especially when campaigns are not geotargeted [01:09:54] yeah, geoip code should not be able to stop the banner [01:13:41] ejegg: ah ha, totally reproduceable. if i remove geoip cookie, ublock blocks the lookup and the banner does not show [01:13:55] do you think that is worth adding to the ticket? [01:14:30] nah, i'm pretty sure we're not doing any client-side lookup in prod [01:14:39] all set by varnish [01:14:49] ooh yeah, nuts [01:15:57] i'm assuming they thought of ad blockers as probable causes of banners not showing anyway [01:16:21] eileen1: I'm confused - the UPDATE civicrm_address command was in the process list, and now it isn't, but drush hasn't reported back yet [01:17:09] ejegg: I've noticed it shows up & then doesn't & then does - must be something about how mysql presents the process [01:17:18] I'm now seeing 1046 seconds [01:17:46] huh [01:18:20] ie running for that long [01:19:08] I see it again [01:21:31] some job is still importing too [01:23:17] what is bothering me is that the things that are failing are failing on tables that are NOT civicrm_address [01:23:22] fredge and banner impressions shouldn't touch any of those tables [01:24:00] cwd: sorry I just saw the require stuff... Were you using debug mode? Also, what version of core were you on? [01:25:02] the "require" stuff is pretty recent [01:25:52] AndyRussG: yeah it was just an old version of core [01:26:23] i discovered that my ad blocker breaks the banner if it's doing that freegeoip lookup [01:26:31] eileen1: I'll be right back - sorry, really didn't expect this to take so long [01:26:34] it blocks the domain which makes the banner not show up [01:26:44] cwd: funny! [01:26:54] ejegg|brb: thx for finding that that hack is no longer needed!! [01:27:37] Fortunately the lookupmodule is not enabled on WMF production [01:27:50] Possible someone else's MW production, though [01:29:45] yeah. i notice the script still gets included, but i guess it bails if the cookie has already been set by varnish? [01:31:54] cwd: the script shouldn't get included... [01:32:12] well no, I mean, the free lookup one shouldn't [01:32:28] ah yeah sorry, the regular geoIp one i mean [01:35:02] Ah yes right [01:35:36] Yeah if there's no cookie and no lookup module, bale and fail the GeoIP promise, IIRC [01:35:58] (Here's where it loads the optional module if needed: https://github.com/wikimedia/mediawiki-extensions-CentralNotice/blob/1f4531bc608bc9a18baf50942d03cedd476c7bd2/resources/subscribing/ext.centralNotice.geoIP.js#L123 ) [01:38:33] IT finished! [01:38:49] AndyRussG: the sub-script dying and taking the banner with it could be interesting though. the enwiki Seinfeld article with debug=true is 252 requests. plenty of opportunities for that kind of thing to happen... [01:40:58] i wonder if anything else in the stack relies on an external request? ad blocker behavior is hard to reason about at scale [01:44:50] phew, finally finished geocoding [01:46:38] well, I guess we've got enough donations in the queue for a load test [01:46:57] !log enabled CiviCRM queue consumers and dedupe jobs [01:47:03] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log [01:50:10] 347 imported in 90 seconds [01:55:52] ok, it's too darn late here. good night all! [01:59:30] cwd: I think there are somethings affected by adblocking... Once we had to deal with the beacon/impression thing being blocked. But I don't think it's the standard blocking people use [01:59:45] I have adblock and it doesn't keep banners from showing, and I didn't whitelist or anything [02:00:41] it'd sure be unfortunate if they did start blocking us for realz [02:03:25] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, Epic: Deal with diacritic conflicts on name checks - https://phabricator.wikimedia.org/T149763#2762103 (Eileenmcnaughton) [02:03:26] yeah, my guess would be an incidental thing, a lot of them "learn" now [02:04:15] but i don't think even the ad blockers want wikipedia to go away ;) [02:44:11] cwd: heh good point [02:45:11] wrt debug=true, I think it's generally not a recommended JS debug route these days, kinda deprecatedish. If possible betted debugging w/ just the prettifying file option in the browser tools [06:19:50] (PS1) Ejegg: Allow banner history IDs less than 16 digits long [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/319269 [13:42:11] Fundraising-Backlog, fundraising-tech-ops: remove 'stomp' project from fundraising code deployment tools - https://phabricator.wikimedia.org/T149695#2763311 (Jgreen) [13:46:43] Fundraising-Backlog, fundraising-tech-ops: recurring contribution queue monitoring is broken since overhaul - https://phabricator.wikimedia.org/T149802#2763325 (Jgreen) [13:46:57] Fundraising-Backlog, fundraising-tech-ops: recurring contribution queue monitoring is broken since overhaul - https://phabricator.wikimedia.org/T149802#2763338 (Jgreen) p:Triage>Unbreak! [14:11:57] Fundraising-Backlog, fundraising-tech-ops: recurring contribution queue monitoring is broken since overhaul - https://phabricator.wikimedia.org/T149802#2763393 (Jgreen) It looks like the column 'next_sched_contribution' may just have been renamed, queries adjusted and it ~looks~ right. @Ejegg @cwdent is... [14:25:32] Fundraising-Backlog, MediaWiki-extensions-DonationInterface: Autofocus on first field (First Name) on payments.wiki - https://phabricator.wikimedia.org/T149803#2763417 (spatton) [17:00:16] fr-tech: Ontogeny recapitulates phylogeny. [17:00:16] -- discuss. [17:04:19] fr-tech i'm in the matrix channel if anyone wants to -talk [17:04:46] I don't really have anything but I'll pop over there in a minute. [17:05:08] ejegg: I'll try... I'm having network trubblz, but I would love some feedback on a comment about Aaron's CN patch... [17:05:40] I'd like some input on https://phabricator.wikimedia.org/T149746 [17:06:30] one sec! [17:10:36] BTW https://gerrit.wikimedia.org/r/#/c/318488 [17:11:22] Fundraising Sprint Unbreaking Now, Fundraising-Backlog, MediaWiki-extensions-DonationInterface, Patch-For-Review, Unplanned-Sprint-Work: Stop using low resolution credit card icons - https://phabricator.wikimedia.org/T149370#2764050 (Ejegg) This is ready to go. @MeganHernandez_WMF, @Pcoombe ,... [17:18:10] fr-tech it's almost time for scrum of scrums [17:18:35] any news or requests? [17:19:06] ejegg: nothing here... we're in the tech talk riot if u want to take 10 min to go thru anything [17:19:06] None here [17:19:32] Oh, there's a separate channel for tech talk? [17:20:03] derp, I had a call going in the freenode channel [17:39:55] Fundraising Sprint Unbreaking Now, Fundraising-Backlog, MediaWiki-extensions-DonationInterface, Patch-For-Review, Unplanned-Sprint-Work: Stop using low resolution credit card icons - https://phabricator.wikimedia.org/T149370#2764190 (Pcoombe) I'm fine with deploying these now @Ejegg [17:50:35] XenoRyet: I never got to the DonationInterface deploy last night - want to push that up? [17:51:25] Sure. Was it just my patch going out, or was there something else on deck? [17:51:51] XenoRyet: the email domain list and the new card logos [17:52:07] Cool. Yea, I'll do that deploy now. [17:52:12] thanks! [18:00:41] (PS1) XenoRyet: Merge branch 'master' into HEAD [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/319366 [18:01:54] (CR) jenkins-bot: [V: -1] Merge branch 'master' into HEAD [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/319366 (owner: XenoRyet) [18:03:33] well that's annoying [18:03:38] when did that change? [18:03:42] Yea, what's going on there? [18:03:56] I guess it's trying to run tests via composer [18:04:05] but we don't actually want that on the deploy branch [18:04:17] I'll take a look at config [18:04:24] 10-4 [18:04:32] in the meantime I think you can remove jenkins-bot and force the merge [18:05:36] How do I do that? [18:05:55] you should be able to click an X next to jenkins-bot in the reviewers list [18:05:59] Oh, just take it off as a reviewer. [18:06:03] then v+2 it yourself [18:06:05] and submit [18:06:19] Ah, yea. Didn't see the reviewers box up there. [18:06:40] (CR) XenoRyet: [C: 2] Merge branch 'master' into HEAD [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/319366 (owner: XenoRyet) [18:07:06] Oh, weird. I can't V+2. I only get V0 and -1 [18:10:00] oops... that's not going to deployment! [18:10:17] 'Merge branch 'master' into HEAD' [18:10:24] Oh, whoops. How did I manage that? [18:10:53] heh, i dunno. got off the branch somehow before merging [18:11:22] So abandon this one and start over? [18:11:26] yeah [18:11:36] (Abandoned) XenoRyet: Merge branch 'master' into HEAD [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/319366 (owner: XenoRyet) [18:13:27] Fundraising Sprint Unbreaking Now, Fundraising-Backlog, fundraising-tech-ops, FR-2016-17-Q2-Campaign-Support: Verify and update host key for AstroPay audit server - https://phabricator.wikimedia.org/T149065#2764307 (Ejegg) Open>Resolved [18:15:18] (PS1) XenoRyet: Merge branch 'master' into HEAD [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/319370 [18:16:04] That landed on master again. I don't know how I'm getting off the deploy branch. [18:17:24] (Abandoned) XenoRyet: Merge branch 'master' into HEAD [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/319370 (owner: XenoRyet) [18:19:24] XenoRyet what does git branch say? [18:20:01] fundraising-tech-ops, Operations, ops-codfw: payments2002 disk failure - https://phabricator.wikimedia.org/T149646#2764363 (Papaul) Received the disk but it was the wrong one. I had to send it back for replacement. [18:20:32] detached from origin/deployment, and a list of the patches we're trying to deploy. [18:23:22] (PS7) Ejegg: Use ct_id to find completed, avoid race [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/312563 (https://phabricator.wikimedia.org/T143945) [18:23:40] XenoRyet: try 'git checkout deployment' [18:23:50] then 'git reset --hard origin/deployment' [18:25:42] I don't have a local deployment branch, so git checkout deployment doesn't work. That hasn't messed with me in the past though. [18:25:52] I'll make one and see if that helps though. [18:25:53] XenoRyet: oh weird! [18:26:03] git checkout origin/deployment ought to do that [18:26:10] ohhhh.... I know the issue [18:26:28] That puts me in detached head at origin/deployment. [18:26:35] huh, ok [18:26:50] I guess you need to git checkout -b deployment [18:27:24] and set it to track from origin/deployment, yea? [18:27:33] yah [18:28:25] ok, let me try the usual voodoo from here. [18:30:36] (PS1) XenoRyet: Merge branch 'master' into deployment [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/319372 [18:30:49] There we go. [18:30:55] Weird that it worked before though. [18:31:12] (CR) XenoRyet: [C: 2] Merge branch 'master' into deployment [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/319372 (owner: XenoRyet) [18:31:55] (CR) jenkins-bot: [V: -1] Merge branch 'master' into deployment [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/319372 (owner: XenoRyet) [18:32:21] I guess jenkins still hates it though. [18:33:20] (CR) jenkins-bot: [V: -1] Merge branch 'master' into deployment [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/319372 (owner: XenoRyet) [18:33:38] heh, won't let me take him off either. [18:34:21] XenoRyet: that's still merging into master [18:34:35] even with that new -1 in there? [18:34:50] oh wait. [18:34:56] what the heck. [18:35:05] (PS1) Ejegg: Downgrade missing details to warning for RecordCaptureJob [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/319373 [18:35:12] (Abandoned) XenoRyet: Merge branch 'master' into deployment [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/319372 (owner: XenoRyet) [18:35:29] XenoRyet: if you look at .gitreview, you'll see it no longer has the 'defaultbranch' attribute [18:35:39] instead it's got the 'track=1' attribute [18:36:07] which /SHOULD/ tell gerrit to merge against whatever upstream branch you're tracking [18:37:02] git branch -vv should show that [18:37:30] mine: deployment fee120f [origin/deployment] Merge branch 'master' into deployment [18:38:19] Yea, that's mine too. [18:38:38] dang [18:39:00] lemme see... maybe that's a newer git-review feature? [18:40:10] XenoRyet: ok, looks like you can specify git-review --track deployment [18:40:55] should that be origin/deployment? [18:41:25] err, I think just deployment [18:42:06] since that's how it shows up in the gerrit UI [18:42:37] git-review didn't recognize that argument. [18:43:27] (PS2) Ejegg: Downgrade missing details to warning for RecordCaptureJob [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/319373 [18:43:59] hmm [18:44:35] git review -r origin/deployment maybe? [18:45:03] or maybe just git review deployment [18:46:13] try that last one [18:46:14] (PS1) XenoRyet: Merge branch 'master' into deployment [extensions/DonationInterface] (deployment) - https://gerrit.wikimedia.org/r/319377 [18:46:22] that looks good! [18:46:38] (CR) XenoRyet: [C: 2] Merge branch 'master' into deployment [extensions/DonationInterface] (deployment) - https://gerrit.wikimedia.org/r/319377 (owner: XenoRyet) [18:46:54] weird that I've never had to do that before, but eh. [18:48:38] (Merged) jenkins-bot: Merge branch 'master' into deployment [extensions/DonationInterface] (deployment) - https://gerrit.wikimedia.org/r/319377 (owner: XenoRyet) [18:53:20] (PS1) Ejegg: Fix regex typo [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/319378 [18:53:45] fr-tech two trivial crm fixes for review. ^^^ [18:54:08] and https://gerrit.wikimedia.org/r/319269 [18:56:27] trivial as in single-character changes [18:56:40] (PS1) XenoRyet: Update DonationInterface Submodule [core] (fundraising/REL1_27) - https://gerrit.wikimedia.org/r/319379 [18:58:36] (CR) XenoRyet: [C: 2] Update DonationInterface Submodule [core] (fundraising/REL1_27) - https://gerrit.wikimedia.org/r/319379 (owner: XenoRyet) [19:07:10] (Merged) jenkins-bot: Update DonationInterface Submodule [core] (fundraising/REL1_27) - https://gerrit.wikimedia.org/r/319379 (owner: XenoRyet) [19:16:23] !log updated DonationInterface from e86f23a371e75a1684de5c102c06d993ead660e0 to ed98772ead6365d58356294ddd46bc4312204b1d [19:16:29] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log [19:20:32] Fundraising Sprint Stirring The Pot, Fundraising Sprint Testing on Production, Fundraising Sprint Unbreaking Now, Fundraising-Backlog, and 5 others: Adyen GB form not loading correctly - https://phabricator.wikimedia.org/T147475#2764650 (XenoRyet) Fix is deployed and the Adyen GB form is ready fo... [19:23:37] fr-tech I need to relocate to an outlet - back soon! [19:46:03] matrix standup? [19:46:12] I was just going to ask. [19:46:16] I'm up for it. [19:48:53] hmm can I join that once it is started [19:49:22] eileen1: Yea, it's up now. [19:50:10] can someone send the link to riot again? I'm trying to call in from the collab computer [19:51:12] riot.im/app [19:52:09] Fundraising Sprint Stirring The Pot, Fundraising Sprint Testing on Production, Fundraising Sprint Unbreaking Now, Fundraising-Backlog, and 5 others: Adyen GB form not loading correctly - https://phabricator.wikimedia.org/T147475#2764821 (Pcoombe) All right! Two apparently successful donations, on... [19:53:07] It's taking a long time to sign in [19:53:46] fundraising-tech-ops: Yubikey for Thea Skaff, fundraising consultant - https://phabricator.wikimedia.org/T149839#2764823 (spatton) [19:54:05] I'm in riot but not getting the conference call [20:00:31] Fundraising-Backlog, fundraising-tech-ops: recurring contribution queue monitoring is broken since overhaul - https://phabricator.wikimedia.org/T149802#2764865 (Eileenmcnaughton) that column was renamed - but a long time ago so I'm a bit confused [20:02:52] (PS1) Ejegg: Drop some unused indexes on silverpop export table [wikimedia/fundraising/tools] - https://gerrit.wikimedia.org/r/319393 [20:04:03] (PS1) Ejegg: Merge branch 'master' into deploy [wikimedia/fundraising/tools] (deploy) - https://gerrit.wikimedia.org/r/319395 [20:04:17] (CR) Ejegg: [C: 2] Merge branch 'master' into deploy [wikimedia/fundraising/tools] (deploy) - https://gerrit.wikimedia.org/r/319395 (owner: Ejegg) [20:09:16] Fundraising Sprint Stirring The Pot, Fundraising Sprint Testing on Production, Fundraising Sprint Unbreaking Now, Fundraising-Backlog, and 5 others: New failmail from recurring queue consumer - https://phabricator.wikimedia.org/T147487#2764954 (Ejegg) Some of these are also due to old missing sub... [20:10:40] Fundraising-Backlog, fundraising-tech-ops: recurring contribution queue monitoring is broken since overhaul - https://phabricator.wikimedia.org/T149802#2764958 (Jgreen) I noticed this today when I fixed a screwy mail filter and started seeing cronspam I had been missing. The nagios test has probably bee... [20:12:17] Fundraising Sprint Testing on Production, Fundraising Sprint Unbreaking Now, Fundraising-Backlog, Patch-For-Review, and 3 others: Fix email address validation on donation form to allow yahoo.ca addresses - https://phabricator.wikimedia.org/T148970#2764972 (Ejegg) Open>Resolved OK, we've a... [20:14:35] Fundraising Sprint Unbreaking Now, Fundraising-Backlog, FR-Adyen, Easy, and 2 others: Make a form without city/state for a test - https://phabricator.wikimedia.org/T86239#964325 (DStrine) [20:15:25] Fundraising-Backlog, fundraising-tech-ops: Figure out why we can't get information about the causes of deadlocks - https://phabricator.wikimedia.org/T149275#2764986 (Jgreen) http://dev.mysql.com/doc/refman/5.5/en/innodb-parameters.html#sysvar_innodb_print_all_deadlocks The documentation isn't terribly c... [20:18:00] (PS1) Eileen: CRM-19337 fix contact sub_type display on reports [wikimedia/fundraising/crm/civicrm] - https://gerrit.wikimedia.org/r/319397 [20:27:05] Fundraising-Backlog, fundraising-tech-ops: recurring contribution queue monitoring is broken since overhaul - https://phabricator.wikimedia.org/T149802#2766018 (Eileenmcnaughton) It might have been nearly a year ago.... [20:27:22] Fundraising Sprint Testing on Production, Fundraising Sprint Unbreaking Now, Fundraising-Backlog, FR-Ingenico, FR-2016-17-Q2-Bugs: Duplicate Ingenico iframe bug - https://phabricator.wikimedia.org/T143430#2766032 (DStrine) Open>Resolved [20:28:15] XenoRyet: on matrix? [20:32:00] Fundraising-Backlog, fundraising-tech-ops: recurring contribution queue monitoring is broken since overhaul - https://phabricator.wikimedia.org/T149802#2766115 (Jgreen) Yup, so we've had no monitoring of that queue since whenever this change happened. [20:32:42] cwd: Yea, going to run both for a while, see how it works out. [20:35:28] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, FR-2016-17-Q2-Campaign-Support: Periodically run Civi contact import performance tests, note trends - https://phabricator.wikimedia.org/T146338#2766159 (Ejegg) We had an informal test last night when we turned the queue consumer off for over an hour... [20:37:47] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, FR-2016-17-Q2-Campaign-Support: Periodically run Civi contact import performance tests, note trends - https://phabricator.wikimedia.org/T146338#2766165 (Eileenmcnaughton) For what it is worth there is one unnecessary stand out query that runs very o... [20:43:41] fundraising-tech-ops: Yubikey for Thea Skaff, fundraising consultant - https://phabricator.wikimedia.org/T149839#2766182 (Jgreen) @spatton, could you add contract info here: https://collab.wikimedia.org/wiki/Fundraising/contractors [20:46:47] Fundraising-Backlog, fundraising-tech-ops: recurring contribution queue monitoring is broken since overhaul - https://phabricator.wikimedia.org/T149802#2766189 (Eileenmcnaughton) OK - well I can definitely confirm the field name changed from next_sched_contribution to next_sched_contribution_date - proba... [20:47:41] i quit the irc channel but i still see myself. i think the bridge has some trouble with the nick list [20:57:27] fundraising-tech-ops: Yubikey for Thea Skaff, fundraising consultant - https://phabricator.wikimedia.org/T149839#2766216 (spatton) Sure @Jgreen, done: https://collab.wikimedia.org/wiki/Fundraising/contractors [21:02:56] Fundraising Sprint Stirring The Pot, Fundraising Sprint Testing on Production, Fundraising Sprint Unbreaking Now, Fundraising-Backlog, and 5 others: New failmail from recurring queue consumer - https://phabricator.wikimedia.org/T147487#2694067 (Eileenmcnaughton) @Ejegg this was 'done' last time -... [21:04:01] Fundraising Sprint Stirring The Pot, Fundraising Sprint Testing on Production, Fundraising Sprint Unbreaking Now, Fundraising-Backlog, and 5 others: New failmail from recurring queue consumer - https://phabricator.wikimedia.org/T147487#2766251 (Ejegg) Yeah, sounds good. We can pull that other tic... [21:20:03] Fundraising-Analysis, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, FR-2016-17-Q2-Campaign-Support: Unnecessary queries on api calls - https://phabricator.wikimedia.org/T148688#2730061 (Ejegg) Yeah, let's definitely cache this stuff! This is _civicrm_api3_custom_fields_for_entity, right? So... [21:21:04] Fundraising Sprint Stirring The Pot, Fundraising Sprint Testing on Production, Fundraising Sprint Unbreaking Now, Fundraising-Backlog, and 5 others: New failmail from recurring queue consumer - https://phabricator.wikimedia.org/T147487#2694067 (Ejegg) Open>Resolved [21:21:20] Fundraising-Analysis, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, FR-2016-17-Q2-Campaign-Support: Unnecessary queries on api calls - https://phabricator.wikimedia.org/T148688#2766351 (Eileenmcnaughton) We'd reduce it to one query per job per entity. [21:23:14] Fundraising Sprint Unbreaking Now, Fundraising-Backlog, Patch-For-Review, WMF-deploy-2016-11-08_(1.29.0-wmf.2): Show contribution tracking ID in Ingenico error messages as full 'External Reference #' - https://phabricator.wikimedia.org/T149137#2766354 (Ejegg) This is deployed - the error should n... [21:23:26] Fundraising Sprint Unbreaking Now, Fundraising-Backlog, Patch-For-Review, WMF-deploy-2016-11-08_(1.29.0-wmf.2): Show contribution tracking ID in Ingenico error messages as full 'External Reference #' - https://phabricator.wikimedia.org/T149137#2766355 (Ejegg) Open>Resolved [21:27:14] (PS1) XenoRyet: Adyen US form without address fields [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/319414 [21:28:27] (PS2) XenoRyet: Adyen US form without address fields [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/319414 (https://phabricator.wikimedia.org/T86239) [21:28:50] fr-tech: Easy one there if someone has a second for review ^ [21:29:12] (CR) Ejegg: "maybe keep postal code?" [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/319414 (https://phabricator.wikimedia.org/T86239) (owner: XenoRyet) [21:29:44] Fundraising Sprint Unbreaking Now, Fundraising-Backlog, FR-Adyen, Easy, and 3 others: Make a form without city/state for a test - https://phabricator.wikimedia.org/T86239#2766378 (XenoRyet) a:XenoRyet [21:33:03] Fundraising Sprint Unbreaking Now, Fundraising-Backlog, FR-Adyen, Easy, and 3 others: Make a form without city/state for a test - https://phabricator.wikimedia.org/T86239#964325 (Ejegg) We just added a table of US zip codes with city & state to Civi. It shouldn't be too hard to wire that up to th... [21:34:31] (CR) Ejegg: "I think we still need street address too" [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/319414 (https://phabricator.wikimedia.org/T86239) (owner: XenoRyet) [21:34:37] ejegg: Do you think we want to keep street too? [21:34:40] heh, jinx [21:34:47] hehe [21:35:35] Ok, patch inbound. [21:36:40] (PS3) XenoRyet: Adyen US form without city/state fields [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/319414 (https://phabricator.wikimedia.org/T86239) [21:39:01] (CR) Ejegg: "Error: Billing address is incomplete" [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/319414 (https://phabricator.wikimedia.org/T86239) (owner: XenoRyet) [21:39:36] Maybe we can generalize that NA-stuffing [21:40:28] or if we had to, I guess we could add that CSV file with the zip / city / state, and stick it in Memcache [21:40:39] Right, worked with no address fields, but I bet street and zip trigger the validation. Yea, the NA thing should be able to do the trick. [21:40:59] That might be a more permanent solution, but I think just for testing the NA thing is good enough. [21:50:00] (PS1) Ejegg: Geocoding: trim zip to 5 characters before lookup [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/319443 (https://phabricator.wikimedia.org/T148578) [21:50:22] Another tiny fix, needed for the timezone thing ^^^ [21:51:37] (PS4) XenoRyet: Adyen US form without city/state fields [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/319414 (https://phabricator.wikimedia.org/T86239) [21:52:23] !log updated fundraising tools from f83e39291adc55677fc4b49307dc4807eba18019 to 7ff719a466bb9ecbdb5f444f67d67903456f6fdb [21:52:30] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log [21:52:43] (CR) XenoRyet: [C: 2] Geocoding: trim zip to 5 characters before lookup [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/319443 (https://phabricator.wikimedia.org/T148578) (owner: Ejegg) [21:53:59] Fundraising Sprint Testing on Production, Fundraising Sprint Unbreaking Now, Fundraising-Backlog, FR-2016-17-Q2-Campaign-Support, Patch-For-Review: Add time zone data back into Silverpop export file - https://phabricator.wikimedia.org/T148578#2726775 (Ejegg) OK @CCogdill_WMF , this is deploye... [21:54:15] thanks XenoRyet ! [21:54:20] No worries. [21:54:22] looking at your ps4 [21:55:03] (CR) jenkins-bot: [V: -1] Adyen US form without city/state fields [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/319414 (https://phabricator.wikimedia.org/T86239) (owner: XenoRyet) [21:55:04] Fundraising Sprint Testing on Production, Fundraising Sprint Unbreaking Now, Fundraising-Backlog, FR-2016-17-Q2-Campaign-Support, Patch-For-Review: Add time zone data back into Silverpop export file - https://phabricator.wikimedia.org/T148578#2766540 (CCogdill_WMF) Okay sounds good. Thanks ve... [21:55:48] Eh, looks like I've got some fixing up to do anyway. [21:56:05] (Merged) jenkins-bot: Geocoding: trim zip to 5 characters before lookup [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/319443 (https://phabricator.wikimedia.org/T148578) (owner: Ejegg) [21:56:59] (CR) Ejegg: "Maybe this could be an address staging helper? It could just stuff all the blank address fields with 'NA' when any of them are set." [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/319414 (https://phabricator.wikimedia.org/T86239) (owner: XenoRyet) [21:58:00] (CR) XenoRyet: "Yea, that's a good idea. I suspected there was a better way than this." [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/319414 (https://phabricator.wikimedia.org/T86239) (owner: XenoRyet) [22:13:02] here i am on my own matrix homeserver [22:21:15] (PS3) Eileen: Rename decile value options. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/319014 (https://phabricator.wikimedia.org/T147965) [22:21:17] (PS3) Eileen: Set gift field on import for contributions over 999. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/319017 (https://phabricator.wikimedia.org/T138361) [22:22:58] @cwd[m] I feel like bursting into "Here I go again on my own" in response to that [22:28:24] Hey all. I'm going to relocate back to the east bay. [22:28:57] cwd cool! [22:32:38] it was a pain in the ass to set up [22:38:49] (PS1) Ejegg: Fill in missing city and state from US zip code [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/319480 (https://phabricator.wikimedia.org/T86239) [22:40:25] vagrant patch to kill activemq: https://gerrit.wikimedia.org/r/#/c/317862/ [22:40:42] oughtta save some ram and battery life for anyone doing their FR dev in vagrant [22:41:01] hmm, not sure if that actually removes an installed service though [22:41:30] we generally don't worry about cleanup. that's what `vagrant destroy -f` is for [22:41:40] right on [22:42:11] going to relocate [23:05:45] Fundraising Sprint Unbreaking Now, Fundraising-Backlog, FR-Smashpig, Unplanned-Sprint-Work: Capture Adyen payments without pending messages - https://phabricator.wikimedia.org/T149861#2766744 (Ejegg) [23:06:38] (PS1) Ejegg: WIP capture Adyen payments missing pending messages [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/319489 (https://phabricator.wikimedia.org/T149861) [23:07:05] I think ^^^ should eliminate the main remaining source of queue-related failmail [23:07:47] (CR) jenkins-bot: [V: -1] WIP capture Adyen payments missing pending messages [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/319489 (https://phabricator.wikimedia.org/T149861) (owner: Ejegg) [23:08:46] (Abandoned) Ejegg: WIP implement length for Predis and PDO backends [wikimedia/fundraising/php-queue] - https://gerrit.wikimedia.org/r/314209 (https://phabricator.wikimedia.org/T147226) (owner: Ejegg) [23:09:37] fr-tech before I fix the tests for that, can anyone take a look and tell me if that strategy actually makes any sense? [23:10:34] ejegg: 319489? [23:11:40] cwd[m]: yeah [23:12:13] hmm, how come the order id stays the same? [23:12:38] cwd[m]: not sure - we definitely give a new one with each new iframe request [23:12:52] but if the donor can re-post the iframe form that might do it [23:13:07] (PS1) Eileen: Fix enotices due to passing wrong params to watchdog() [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/319491 [23:13:53] (CR) Ejegg: [C: 2] "Oops, thanks for the fix!" [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/319491 (owner: Eileen) [23:15:24] (CR) Ejegg: [C: 2] Rename decile value options. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/319014 (https://phabricator.wikimedia.org/T147965) (owner: Eileen) [23:18:51] ejegg: is this a separate payments_fraud table in smashpig? does it read from fredge/ [23:18:54] ? [23:19:16] cwd[m]: it'll read from fredge, like the PaymentsInitial class [23:19:24] (PS1) Eileen: Further e-notic fix. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/319492 [23:19:38] why the schema files in that case? [23:20:16] cwd[m]: mostly 'cause we need them for tests [23:20:17] (Merged) jenkins-bot: Rename decile value options. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/319014 (https://phabricator.wikimedia.org/T147965) (owner: Eileen) [23:20:59] does the idea of keeping them in sync across the repos make you nervous at all? [23:20:59] but if smashpig depends on something, i want it to know how to create it. Then maybe we can take the definitions out of the higher level apps and route all access through smashpig classes [23:21:02] the structure of those tables [23:21:19] (PS2) Eileen: Further e-notice fix. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/319492 [23:21:24] cwd[m]: yeah, those tables are beasts to alter anyway [23:21:58] (PS4) Ejegg: Set gift field on import for contributions over 999. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/319017 (https://phabricator.wikimedia.org/T138361) (owner: Eileen) [23:27:22] (CR) Ejegg: [C: 2] Set gift field on import for contributions over 999. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/319017 (https://phabricator.wikimedia.org/T138361) (owner: Eileen) [23:28:59] (PS2) Ejegg: Fix enotices due to passing wrong params to watchdog() [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/319491 (owner: Eileen) [23:30:05] (PS3) Ejegg: Further e-notice fix. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/319492 (owner: Eileen) [23:30:12] (CR) Ejegg: [C: 2] Further e-notice fix. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/319492 (owner: Eileen) [23:33:42] (PS3) Ejegg: WIP queueWrapper [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/316387 [23:35:26] (CR) jenkins-bot: [V: -1] WIP queueWrapper [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/316387 (owner: Ejegg) [23:37:23] (Merged) jenkins-bot: Set gift field on import for contributions over 999. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/319017 (https://phabricator.wikimedia.org/T138361) (owner: Eileen) [23:39:06] Fundraising Sprint Stirring The Pot, Fundraising Sprint Testing on Production, Fundraising Sprint Unbreaking Now, Fundraising-Backlog, and 5 others: Adyen GB form not loading correctly - https://phabricator.wikimedia.org/T147475#2766921 (XenoRyet) Open>Resolved [23:39:47] (Merged) jenkins-bot: Fix enotices due to passing wrong params to watchdog() [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/319491 (owner: Eileen) [23:39:49] (Merged) jenkins-bot: Further e-notice fix. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/319492 (owner: Eileen) [23:41:08] (CR) Cdentinger: "This seems like a big reaction, I wonder if there's something we could do further upstream to prevent getting in that situation in the fir" [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/319489 (https://phabricator.wikimedia.org/T149861) (owner: Ejegg) [23:41:21] back in a bit [23:48:44] (PS1) Eileen: Backfill gift so that donations of 000+ have a gift source. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/319497 (https://phabricator.wikimedia.org/T138361) [23:49:36] Fundraising Sprint Testing on Production, Fundraising Sprint Unbreaking Now, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, and 2 others: Not all online donations getting tagged to Restrictions and Gift Source Fields - https://phabricator.wikimedia.org/T138361#2766942 (Eileenmcnaughton) From...