[00:00:11] thanks awight! [00:00:30] np! [00:00:32] If you have any input on the can't-merge-yet patches, I'd be happy to hear it [00:00:57] Okay, I'll take more looks and +1 in the event that I've grokked [00:01:12] thanks! [00:01:27] ok, heading out for the eve [00:03:37] (PS3) Awight: Use IDENTIFIER constants instead of strings [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/301311 (owner: Ejegg) [00:10:06] (CR) Awight: [C: 2] "I'm a little scared that PHP 5.3 will treat these as expressions... we'll see!" (1 comment) [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/301311 (owner: Ejegg) [00:11:26] awight: if you have a moment I just wanted to talk languages with you [00:11:29] (Merged) jenkins-bot: Use IDENTIFIER constants instead of strings [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/301311 (owner: Ejegg) [00:11:35] (CR) Awight: [C: 2] "Thank you!" [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/303266 (owner: Reedy) [00:12:50] my thinking is I should 1) do some queries to find out what our discrepancies are between CiviCRM & the contribution_tracking calculation [00:13:06] (Merged) jenkins-bot: Update package.json [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/303266 (owner: Reedy) [00:13:13] & look to fix the import scripts so that the language is correct on contribution-import [00:13:22] ie. updated to match the most recent contribution [00:13:42] eileen: Perfect, thanks for taking the time to do the queries [00:13:45] & then we should just use the CiviCRM language for silverpop [00:13:59] (which would save time & give MB & CC more control) [00:14:00] The big thing is that contribution_tracking language might have the correct language variant, and CRM won't [00:14:11] pt_BR is a good test case [00:14:14] and that is mostly for historical reasons? [00:14:31] or we still aren't bring that data through correctly? [00:14:43] what is pt_BR? [00:15:35] Brazilian Portuguese [00:15:41] * awight wipes brow after spelling bee [00:16:07] We *might* be bringing the data over correctly now, but certainly not in the past. [00:16:17] oh, zh-Hans is another example of total fail [00:17:57] hmm it's going to be hard to do queries unless I index language [00:18:13] d'oh. [00:18:22] You could dump all that into your own tables [00:18:36] create eileen.foo select language, contact_id from... style [00:18:58] yeah - looks like I could speed up the silverpop queries by indexing language in the sp tables too [00:19:38] ah ok then [00:19:53] ok - I will do some queries to get an idea of how the data quality is [00:20:13] dang, sorry but I need to run for the evening [00:20:15] but I'm leaning towards thinking we just clean up the data once & make sure it's coming in ok [00:20:22] that's fine - I got my answers [00:20:31] eileen: That's a great idea! thx [05:30:28] Fundraising Sprint Octopus Untangling, Fundraising Sprint Pretending This Isn't Happening, Fundraising-Backlog, MediaWiki-extensions-DonationInterface, and 2 others: Clicking the credit card button multiple times loads duplicate iframes... - https://phabricator.wikimedia.org/T142059#2521233 (XenoR... [08:42:49] (PS1) Awight: test fixups [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/305465 [08:45:58] (CR) jenkins-bot: [V: -1] test fixups [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/305465 (owner: Awight) [09:10:27] (PS2) Awight: Normalize date earlier [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/305198 (https://phabricator.wikimedia.org/T142417) [09:10:29] (PS2) Awight: test fixups [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/305465 [09:10:31] (PS5) Awight: [WIP] Make another DateTime conversion more robust [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/305186 (https://phabricator.wikimedia.org/T140667) [09:17:09] (PS6) Awight: Make another DateTime conversion more robust [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/305186 (https://phabricator.wikimedia.org/T140667) [14:28:24] (CR) Ejegg: [C: 2] test fixups [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/305465 (owner: Awight) [14:29:30] (CR) Ejegg: [C: 2] Normalize date earlier [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/305198 (https://phabricator.wikimedia.org/T142417) (owner: Awight) [14:29:42] (CR) Ejegg: [C: 2] Make another DateTime conversion more robust [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/305186 (https://phabricator.wikimedia.org/T140667) (owner: Awight) [14:31:54] (Merged) jenkins-bot: test fixups [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/305465 (owner: Awight) [14:32:19] (Merged) jenkins-bot: Normalize date earlier [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/305198 (https://phabricator.wikimedia.org/T142417) (owner: Awight) [14:33:33] (Merged) jenkins-bot: Make another DateTime conversion more robust [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/305186 (https://phabricator.wikimedia.org/T140667) (owner: Awight) [14:50:41] (CR) Cdentinger: [C: -1] PHPDoc fixes (1 comment) [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/305116 (owner: Ejegg) [14:50:58] ejegg: no offense! just trying to get comfortable with -1 [14:51:06] but i already feel bad [14:52:40] i don't care for the verbiage "please improve" either. strongly implies that i think i'm right. [14:53:33] heh, no worries [14:55:17] (CR) Ejegg: PHPDoc fixes (1 comment) [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/305116 (owner: Ejegg) [14:55:18] but yeah it's way too easy to ignore/miss stuff with just a comment and no score [14:55:27] totally [15:06:51] (CR) Cdentinger: PHPDoc fixes (1 comment) [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/305116 (owner: Ejegg) [15:06:58] totally pedantic... [15:12:20] Found something you guys will get a kick out of [15:12:23] Trying to book a bus tour [15:12:26] "pay with paypal" [15:12:28] click [15:12:29] string(78) "/var/www/app/_app/app/Http/Controllers/PaymentGateways/PaypalController.php:57" object(stdClass)#400 (4) { ["result"]=> object(stdClass)#398 (3) { ["code"]=> string(11) "200.300.404" ["description"]=> string(28) "invalid or missing parameter" ["parameterErrors"]=> array(1) { [0]=> object(stdClass)#419 (3) { ["name"]=> string(6) "amount" ["value"]=> string(4) "27.1" ["message"]=> string(37) "must match ^[0-9]{1,10}(\.[ [15:12:29] 0-9]{2})?$" } } } ["buildNumber"]=> string(66) "f0738f794262d659e1e22eb7702488e0778191c3@2016-08-18 06:40:05 +0000" ["timestamp"]=> string(24) "2016-08-18 15:11:10+0000" ["ndc"]=> string(65) "8a8394c255e9a5f20155ea05a5080254_e4ae742a1a3f4a508a3529e7ceb25113" } [15:12:35] l2php [15:15:12] oh man, dumping exceptions from payment code [15:15:24] Reedy: that was in the html? [15:15:37] That's literally all it showed on the page [15:15:47] X| [15:15:57] makes you feel nice and secure about your online payments [15:16:28] (CR) Ejegg: PHPDoc fixes (1 comment) [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/305116 (owner: Ejegg) [15:17:16] (PS2) Ejegg: PHPDoc fixes [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/305116 [15:17:46] ejegg: ah yeah that's a better idea! [15:17:58] batten down the hatches [15:19:44] heh [15:21:44] (CR) Cdentinger: [C: 2] PHPDoc fixes [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/305116 (owner: Ejegg) [15:22:41] I'm getting a weird number of missed calls this morning... Anything on fire? [15:23:09] awight|commute: nothing i know of [15:34:01] Oh good, just stalking then ;) [15:34:08] See ya in a few [15:35:54] (Merged) jenkins-bot: PHPDoc fixes [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/305116 (owner: Ejegg) [17:01:00] nice timing [17:01:14] i will get on the phone in a minute [17:01:16] uh, oh [17:01:21] oah 10:00 [17:05:31] brt [17:05:45] Yea, one sec and I'll be in too [17:51:01] Fundraising Sprint Pretending This Isn't Happening, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, FR-ActiveMQ, and 4 others: Audit processors should mirror outbound queue messages - https://phabricator.wikimedia.org/T141484#2500246 (Ejegg) a:Ejegg [17:59:44] Fundraising-Backlog, FR-Smashpig, Epic: [Epic] Move all listener message processing to a second stage - https://phabricator.wikimedia.org/T143342#2565243 (Ejegg) [18:10:09] (PS2) Cdentinger: WIP smashpig paypal listener [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/305172 [18:10:23] awight: ^ that has the test data [18:10:40] woot! [18:11:04] (CR) jenkins-bot: [V: -1] WIP smashpig paypal listener [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/305172 (owner: Cdentinger) [18:19:03] (PS1) Awight: Update composer libs [wikimedia/fundraising/crm/vendor] - https://gerrit.wikimedia.org/r/305553 [18:20:05] (PS1) Awight: Merge master into deployment [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/305554 [18:20:07] (PS1) Awight: Update composer libs [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/305555 [18:20:23] (CR) Awight: [C: 2] Update composer libs [wikimedia/fundraising/crm/vendor] - https://gerrit.wikimedia.org/r/305553 (owner: Awight) [18:20:36] (CR) Awight: [C: 2] Update composer libs [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/305555 (owner: Awight) [18:21:12] (CR) Awight: [C: 2] Merge master into deployment [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/305554 (owner: Awight) [18:22:07] (CR) jenkins-bot: [V: -1] Update composer libs [wikimedia/fundraising/crm/vendor] - https://gerrit.wikimedia.org/r/305553 (owner: Awight) [18:24:07] aww nutes. [18:24:11] and nuts [18:24:16] (Merged) jenkins-bot: Merge master into deployment [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/305554 (owner: Awight) [18:24:18] (Merged) jenkins-bot: Update composer libs [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/305555 (owner: Awight) [18:25:44] ARGH. CallbackFilterIterator [18:25:46] polyfill fail [18:25:47] WAT [18:29:29] We might have to downgrade http-foundation [18:34:23] (PS2) Awight: Update composer libs + hacking [wikimedia/fundraising/crm/vendor] - https://gerrit.wikimedia.org/r/305553 [18:35:00] (CR) Awight: [C: 2] Update composer libs + hacking [wikimedia/fundraising/crm/vendor] - https://gerrit.wikimedia.org/r/305553 (owner: Awight) [18:37:40] (Merged) jenkins-bot: Update composer libs + hacking [wikimedia/fundraising/crm/vendor] - https://gerrit.wikimedia.org/r/305553 (owner: Awight) [18:38:40] hehe take that, php -l [18:40:03] wait. [18:40:48] (PS1) Awight: Update composer libs [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/305557 [18:40:58] (CR) Awight: [C: 2] Update composer libs [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/305557 (owner: Awight) [18:41:03] (Merged) jenkins-bot: Update composer libs [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/305557 (owner: Awight) [18:45:55] !log update civicrm from a30fc0aa2c2dc3a7a9a0b09bef19d112bdf5f98e to 41844071e3018b21f2c36ab692c4b43b92cab8d0 [18:46:00] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log, Master [18:48:57] !log rollback civicrm from 41844071e3018b21f2c36ab692c4b43b92cab8d0 to a30fc0aa2c2dc3a7a9a0b09bef19d112bdf5f98e [18:49:02] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log, Master [18:50:37] This is not gonna work. [18:50:46] What a time sink [18:51:35] http://dailypicksandflicks.com/wp-content/uploads/2012/01/dog-bath-time-in-sink-.jpg [18:54:34] was it the date patches? [19:09:09] (PS6) Ejegg: DO NOT MERGE: import info from pending DB, not AMQ [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/299938 (https://phabricator.wikimedia.org/T122641) [19:10:44] (PS7) Ejegg: DO NOT MERGE: import info from pending DB, not AMQ [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/299938 (https://phabricator.wikimedia.org/T122641) [19:59:40] (PS1) Ejegg: Base class for dbs, they can create tables [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/305568 [19:59:49] Fundraising Sprint Licking Cookies, Fundraising Sprint Muggle Baiting, Fundraising Sprint Nitpicking, Fundraising Sprint Octopus Untangling, and 4 others: Spike: Monitor deployment of: Suppress CentralNotice ResourceLoader modules on Special and act... - https://phabricator.wikimedia.org/T139439#2565646 [19:59:55] Fundraising Sprint Licking Cookies, Fundraising Sprint Muggle Baiting, Fundraising Sprint Nitpicking, Fundraising Sprint Octopus Untangling, and 4 others: Spike: Monitor deployment of: Suppress CentralNotice ResourceLoader modules on Special and act... - https://phabricator.wikimedia.org/T139439#2432367 [20:01:03] Fundraising Sprint Licking Cookies, Fundraising Sprint Muggle Baiting, Fundraising Sprint Nitpicking, Fundraising Sprint Octopus Untangling, and 3 others: Spike: Monitor deployment of: Suppress CentralNotice ResourceLoader modules on Special and act... - https://phabricator.wikimedia.org/T139439#2432367 [20:10:17] awight: standup? [20:17:49] Fundraising Sprint Licking Cookies, Fundraising Sprint Muggle Baiting, Fundraising Sprint Nitpicking, Fundraising Sprint Octopus Untangling, and 6 others: Spike: Monitor deployment rolling back our "googleoff" tag - https://phabricator.wikimedia.org/T137761#2565731 (AndyRussG) Open>Resolved [20:17:55] Fundraising Sprint Licking Cookies, Fundraising Sprint Muggle Baiting, Fundraising Sprint Nitpicking, Fundraising Sprint Octopus Untangling, and 6 others: Spike: Monitor deployment rolling back our "googleoff" tag - https://phabricator.wikimedia.org/T137761#2565730 (AndyRussG) I ran the following... [20:23:34] (PS8) Ejegg: Import info from pending DB, not AMQ [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/299938 (https://phabricator.wikimedia.org/T122641) [20:27:11] Fundraising Sprint Licking Cookies, Fundraising Sprint Muggle Baiting, Fundraising Sprint Nitpicking, Fundraising Sprint Octopus Untangling, and 5 others: Spike: Monitor deployment rolling back our "googleoff" tag - https://phabricator.wikimedia.org/T137761#2565784 (AndyRussG) [20:40:31] (PS1) Ejegg: Check for duplicates before re-queueing MISSING_PREDECESSOR [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/305577 (https://phabricator.wikimedia.org/T122641) [20:43:21] (PS1) Ejegg: FIXME [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/305580 [20:51:19] awight what's the failing commit? [20:53:24] ejegg: It's the top stuff in crm/vendor [20:54:42] ohh, it passed 'cause you removed the polyfill, but that breaks the rest of the library [20:56:18] exactyly [20:56:33] and if u look at the earlier patchset, you can see the php55lint [20:56:43] yah, just peeped it [20:57:59] and this test is just running git-changed-in-head and xargsing it to php5 -l, so no chance for an 'excludes' file [20:58:29] horrific [20:58:35] thanks for taking a look... [20:59:08] bah, let's see how far back we have to go to avoid the polyfill [21:00:43] ooh, SmashPig/vendor isn't running lint - that's why we got away with it there [21:02:17] nuts. Well we could do that! [21:04:55] hmm, but a version constraint would make sense to make sure we don't lose 5.3 compat [21:05:54] well, I guess 2.8 already gets us that [21:06:41] awight: yeah, let's drop the lint (or remove jenkins and force it) [21:06:58] +1 [21:07:17] are you set up to do that, or do you want a hand? [21:07:24] I'm so hosed ATM [21:07:31] k, i'll do it [21:07:32] leaning over two completely dysfunctional computers [21:07:34] ty [21:09:02] CI is hard [21:09:14] but if you think we've got it bad: http://status.openstack.org/zuul/ [21:10:14] 11 hr 59 min .... sadness [21:12:03] (PS1) Ejegg: Re-add polyfill-php54 [wikimedia/fundraising/crm/vendor] - https://gerrit.wikimedia.org/r/305581 [21:12:31] (CR) Ejegg: [C: 2] Re-add polyfill-php54 [wikimedia/fundraising/crm/vendor] - https://gerrit.wikimedia.org/r/305581 (owner: Ejegg) [21:15:17] (CR) jenkins-bot: [V: -1] Re-add polyfill-php54 [wikimedia/fundraising/crm/vendor] - https://gerrit.wikimedia.org/r/305581 (owner: Ejegg) [21:15:35] (CR) Ejegg: [V: 2] Re-add polyfill-php54 [wikimedia/fundraising/crm/vendor] - https://gerrit.wikimedia.org/r/305581 (owner: Ejegg) [21:16:32] (PS1) Ejegg: Update libs [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/305582 [21:16:35] cwd: What's the most important entry point to test first? stage 1 or 2? [21:16:42] seems like stage 2, right? [21:16:59] (CR) Ejegg: [C: 2] Update libs [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/305582 (owner: Ejegg) [21:17:05] (Merged) jenkins-bot: Update libs [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/305582 (owner: Ejegg) [21:17:16] awight: stage 2 as in the consumer part? [21:17:36] the part that calls the PP validate API etc [21:17:40] awight: ready for deploy [21:17:48] ejegg: whoa. awesome [21:18:11] can you get on to logserver ? [21:18:34] awight: does that happen in the tools repo now? [21:18:34] yah [21:18:49] cwd: It's the PaymentsListener/legacy_paypal garbage [21:19:01] ipn_verify method i think [21:19:31] ah so it phones back to paypal before queueing the message? [21:19:33] !log update civicrm from a30fc0aa2c2dc3a7a9a0b09bef19d112bdf5f98e to da572ab911763612a4b7005056821918ac630cbe [21:19:38] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log, Master [21:19:48] cwd: We have some notes in yesterday's tech talk etherpad [21:20:09] The draft idea is that stage 1 gets the raw IPN message and basically just jams it into the job runner queue [21:20:44] Then stage 2 pulls the raw mesage, parses it, make sure it makes sense, then calls out to the validate API. then if everything checks out, pushes to a donation queue [21:21:49] but as the conversation earlier stage 1 still has to do some sort of message parsing [21:21:53] right? [21:22:01] I don't think so [21:22:03] not for PP [21:22:14] since it's just a url query? [21:22:18] It's an open question, but I don't think so [21:22:19] yeah [21:22:42] what would we do if parsing the url bombed? [21:23:06] it would just take the request pairs, maybe json them into a blob [21:23:24] ah so it wouldn't even parse the url? [21:23:33] what would it parse? [21:23:41] I don't think there's much to do [21:23:51] oh well i'm saying what if the url was hosed in such a way that it was unparseable [21:24:00] i guess it would never get there [21:24:02] oh heh good question [21:24:30] eh i think it would just never arrive if it was that bad [21:25:12] so this thing: https://github.com/wikimedia/wikimedia-fundraising-crm/blob/master/sites/all/modules/wmf_common/WmfDatabase.php#L13 [21:25:26] yuck [21:25:30] I did that. [21:25:34] has anyone dug into which resources specifically need locking? [21:25:43] It's to simulate https://en.wikipedia.org/wiki/Two-phase_commit_protocol [21:26:00] i just can't imagine that it doesn't singlehandedly murder civicrm performance [21:26:06] I'm sure it does [21:26:25] well, we can get away from it for most of the new queue consumers! [21:26:27] The problem I was dealing with is, we make a hundred write queries from various pieces of code to various databases, then something goes wrong [21:27:09] I don't know much about it (obviously), but it's also possible for transactions to speed up performance, cos we skip the autocommit after every statement. [21:28:16] yeah i mean i don't think this function is a problem [21:28:25] but the million queries the queue up while it's running... [21:29:04] anyway not something to solve right now [21:29:38] but i bet with some investigation it could be split up into smaller steps with fewer lock requirements [21:29:52] yeah that would be killer [21:31:28] i don't think i've ever started an application-side transaction that i haven't ended up regretting [21:37:38] i had an interesting experience the other day when i added a business too gmaps for the first time [21:37:54] and watched the data become gradually consistent across the infrastructure [21:54:39] (PS4) Ejegg: WIP tests for combining pending DB info [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/300584 (https://phabricator.wikimedia.org/T122641) [21:56:19] (CR) jenkins-bot: [V: -1] WIP tests for combining pending DB info [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/300584 (https://phabricator.wikimedia.org/T122641) (owner: Ejegg) [22:02:38] ejegg: so the amazon race condition is when the pending message hasn't been consumed from redis->mysql by the time the success message arrives? [22:03:50] cwd yep [22:04:16] that's a tough one... [22:04:50] would that be a good case for requeueing with a delay? [22:04:51] but there is almost always a message with the full set of data from the payments front end, that doesn't need the pending message [22:05:09] cwd yeah, the requeue is exactly what happens [22:06:34] the downside is the thank you mail delay? [22:06:56] cwd this patch makes us skip that if we've already got the info from the frontend into civi: https://gerrit.wikimedia.org/r/305577 [22:07:33] cwd right, it would be a delay, but only if we somehow don't get the front end message [22:08:24] by front end message do you mean the success IPN, or contribution_tracking? [22:09:51] we send a message to the completed queue from paymentswiki that has all the data. it's totally redundant to do anything with tbe IPN mesaage [22:10:28] oh right, in contrast to adyen where we wait for the message [22:10:58] but just in case we fail between sending the pending and completed mesaages from paymentswiki, the IPN liatener will catch it [22:11:27] yah, Amazon has an async mode too, but we haven't needed it yet [22:11:51] but the listener is essentially async mode yeah? [22:12:39] yeah, but we don't rely on it to issue the capture command except for adyen [22:15:22] does the amazon listener do anything right now? [22:17:27] just records completed donations and refunds [22:17:43] the refunds aren't redundant at least! [22:17:52] heh [22:18:03] (though the audit parser should be able to get those too) [22:18:10] so it records completed donations if they got lost in space after sending to amazon? [22:18:21] yeah [22:18:32] but you were saying that doesn't really happen very much? [22:19:01] right [22:20:31] despite the redundancy it is nice that we have so many failovers to catch stuff [22:21:42] Fundraising Sprint Pretending This Isn't Happening, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, FR-ActiveMQ: Donation import should merge and delete pending db info - https://phabricator.wikimedia.org/T141477#2566206 (Ejegg) a:Ejegg [22:22:14] yeah, always good when working with money [22:24:54] cwd: I'm not feeling like these tests are going to unblock you... but they're coming right up [22:25:18] ejegg: let's say the completed message comes in and we don't have the pending message, but the donation is in civi, so we delete the completed message... what happens to the pending message when it finally gets moved to mysql? [22:25:25] awight: thanks! and how come? [22:25:54] eh cos I suck at writing tests, and I always do a bunch of iterations of adjusting the tests and the implementation to match each other [22:26:08] cwd guess it sticks around till it expires [22:26:21] so the test won't exactly be usable out of the box [22:26:37] awight: i'm sure it will help me understand the goal anyway [22:27:16] ejegg: what's wrong with requeueing it, and then nuking both when it finally finds the pending msg? [22:27:45] or rather, why is it better to do it up front? [22:28:25] I think if we requeue 10 times and still fail, we send a failmail. [22:29:15] but under most circumstances we shouldn't be more than a minute away from it getting consumed right? [22:29:33] so it seems like that failmail might indeed indicate a problem [22:29:42] pending queue broken or something [22:29:58] right, but if we want to delete pending db entries with the first import (as per T141477), we don't want any subsequent imports to freak out [22:30:22] ah yes... [22:30:29] T141477: Donation import should merge and delete pending db info - https://phabricator.wikimedia.org/T141477 [22:30:40] * awight smiles at stashbot [22:37:12] awight: I'm about ready to merge your CRM / orphans patches, if you're around to monitor recurring donations [22:41:35] oof, sounds great. [22:41:52] Generally, only one job per day actually catches any new charges to process though [22:41:58] The one at UTC midnight or so [22:46:29] (PS1) Awight: [WIP] Skeletal tests for both stages of the PayPal listener [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/305593 (https://phabricator.wikimedia.org/T141654) [22:46:35] cwd: So... lmk if that makes any sense [22:46:46] It won't work even the tiniest bit, but we'll refine from here [22:47:28] (CR) jenkins-bot: [V: -1] [WIP] Skeletal tests for both stages of the PayPal listener [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/305593 (https://phabricator.wikimedia.org/T141654) (owner: Awight) [22:50:13] Hey all! Just a note that we've got a pre-test going up in Japan in 10 minutes, running for the next two hours [22:51:50] awight: thanks! [22:55:30] awight: did writing the tests first feel relevant or useful at all? [22:57:57] awight: Sorry, can you clarify? I don't understand the question. [23:00:02] spatton: Which question? I think it might have been about something else... [23:00:38] cwd: A bit relevant--if it make it more clear what each stage of the listener does & where the entry points are [23:03:16] Ah :) Just me confusing myself with IRC. [23:24:46] awight: gotta run errands but will work with those tests more later. thanks again for writing them! [23:25:33] not done yet! [23:27:12] awight: you do stuff with AC... do you know what the max safe breaker size i can put in a 100 amp panel is? or how i can find out? [23:27:58] scary. you could theoretically take all 100A out of there... with a huge conductor [23:28:13] 50A is fine, use 6-gauge wire or so [23:28:36] 100 amp means 100 from each pole right? so theoretically 200 at 110v [23:28:49] The best reference I've found is actually the fire code: http://www.nfpa.org/codes-and-standards/all-codes-and-standards/list-of-codes-and-standards?mode=code&code=70 [23:29:09] oh perfect [23:29:10] I believe so. [23:30:29] i think i need to wire a new circuit for a water heater. the smallest load i can find for a reasonably sized one is 2000w so ~17 amps at 110 and i have no breakers above 20 [23:30:38] and i read the safe load for 20 amp breaker is like 15 [23:31:14] Also sounds right. And you want to use 10-gauge romex [23:31:14] there is 20amps at 220 but the 220v heaters are 4000w :-\ [23:31:24] weird! [23:31:31] the wattage should be the same for equivalent heating [23:31:49] yeah i'm guessing the 110 ones are just slow? [23:32:57] also just FTR, when you split the 100A 220 power into two phases, it's still 100A per phase [23:33:43] you could kind of call that 200A, if you mean you can have two 100A 110 breakers [23:34:05] yeah so 220 is more like parallel rather than series? [23:34:21] not sure what you mean by "slow", that the 2kw heater heats half as fast as the 4kw one? yeah [23:34:29] yeah that's all i meant [23:35:14] i have certainly heard of people just cutting an extension cord and plugging them in but i'd worry about that romex [23:35:18] n.b. I learned all I know about electricity from a guy who had his hand sewn into his stomach for a few months, while skin grew back after a high line accident ;) [23:35:35] D: [23:35:46] The [23:36:14] If you get a 17A 110 heater, you'll want a 25A or 30A breaker, and then the wiring needs to be able to handle the maximum load of the breaker [23:36:34] yeah [23:37:01] the prospective heater will be like 36" from the panel so adding a new circuit with beefier wire is probably the right choice [23:37:31] There isn't an exact formula for that cos it depends on things, but I'm pretty sure the suggested wire is 10/2 (two conductor 10 AWG per wire) [23:37:38] that should handle 30A 110V [23:38:02] i figure i'll just do 220 as long as there is new wiring involved anyway [23:38:06] i think they are more efficient [23:39:17] Fundraising Sprint Licking Cookies, Fundraising Sprint Muggle Baiting, Fundraising Sprint Nitpicking, Fundraising Sprint Octopus Untangling, and 3 others: Investigate Civi Load Time issue - https://phabricator.wikimedia.org/T138334#2566343 (CaitVirtue) @yeah, i guess. It's better but still could... [23:39:42] anyway thanks for the info! ttyl [23:44:57] 220 is the same btw, you just use 10/3 wire for a 30A breaker. [23:45:21] 4kW will still be 17A, I suppose