[00:21:34] Fundraising-Backlog, MediaWiki-extensions-CentralNotice: Banner previews occasionally fail to load - https://phabricator.wikimedia.org/T200853 (AndyRussG) @Pcoombe ok thanks that's an important details! I'll check server-side errors to see if I can find anything... Has it only happened with the banner l... [00:22:33] ejegg: thx for tracking down T200896!! [00:22:34] T200896: Nothing in pgehres.bannerimpressions table since 2018-07-31 18:29:00 - https://phabricator.wikimedia.org/T200896 [00:22:56] and 4 the speedy fix! :) [00:46:07] (PS3) Eileen: CiviCRM 5.4 [wikimedia/fundraising/crm/civicrm] - https://gerrit.wikimedia.org/r/444769 [01:01:44] cwd I deployed a fix that works well on staging but is giving a 500 error on live https://phabricator.wikimedia.org/T199753 [01:02:26] I saw some suggestion that php timeouts or exceeding the number of worker threads may be involved - the later feels v familiar [01:03:18] I’m struggling to find something in the logs though [01:21:59] ok got it Aug 2 01:21:18 civi1001 drupal: PHP Fatal error: Maximum execution time of 30 seconds exceeded in /srv/org.wikimedia.civicrm/civicrm/packages/DB/DataObject.php on line 4277 [01:22:00] Aug 2 01:21:22 civi1001 drupal: PHP Fatal error: Maximum execution time of 30 seconds exceeded in /srv/org.wikimedia.civicrm/civicrm/packages/DB/DataObject.php on line 2408 [01:31:55] Fundraising Sprint Owls, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: slow anonymous save - https://phabricator.wikimedia.org/T199753 (Eileenmcnaughton) @LeanneS I figured out what is happening - the php timeout on live is only 30 seconds - it's being exceeded when the record is loaded (due to... [02:34:33] eileen: just seeing [02:34:54] do you think a longer timeout is necessary? [02:35:03] cwd yeah - I can try to reduce the php time it takes but a higher timeout would help too I think [02:35:18] on staging it’s working [02:36:47] cwd - this url is where you can see the time out civicrm/contact/view?reset=1&cid=72 [02:38:20] eileen: hrm, timeout appears to be 60s on staging and live [02:38:25] in php.ini [02:38:44] cwd it ust be getting 30 seconds from 'somewhere' [02:39:30] yeah...checking around [02:42:33] eileen: oop yeah indeed there is a different setting max_execution_time [02:43:05] ah yeah I see it - I wonder if we could test 60 seconds [02:43:53] i don't see why not, it is 300 on staging :) [02:48:17] eileen: just curious, don't civi searches often take more than 30s? [02:48:27] cwd yeah - that’s mysql time [02:48:32] this is php iteration time [02:48:47] & in fact it’s gone up on this page because the mysql time went down in a fix [02:48:51] how is that decoupled? isn't php waiting for mysql? [02:49:02] yeah - but it knows that & doesn’t count it [02:53:44] eileen: so this is the only place that php is timing out regularly? [02:54:07] as in raising the limit won't cause mass lockups? [02:54:17] cwd I guess imports do too but they continue in the back ground & then they can refresh to see the outcome [02:54:39] just want to be sure what i'll tell jeff if he asks why :) [02:55:13] cwd I;m happy to try to work on a code fix for that page to improve it such that it might not need the bigger time out [02:55:20] he basically always has a relevant concern i didn't think of [02:55:25] but would prefer the config fix in the meantime [02:55:49] ok [02:55:51] one sec [02:59:36] eileen: ok 60s now [02:59:46] cwd testing [03:01:46] cwd ok - it was slow (I guess up to 60 sec) but it loaded [03:03:42] cool [03:15:57] Fundraising Sprint Owls, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: slow anonymous save - https://phabricator.wikimedia.org/T199753 (Eileenmcnaughton) @LeanneS @cwdent has increased the time out at the php level so the page loads - I do have another path to pursue to speed it up more - disc... [06:58:40] (PS1) Eileen: WIP silverpop erasure [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/449937 (https://phabricator.wikimedia.org/T199747) [07:06:16] (CR) jerkins-bot: [V: -1] WIP silverpop erasure [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/449937 (https://phabricator.wikimedia.org/T199747) (owner: Eileen) [07:39:31] (PS1) Eileen: Update Omnimail silverpop pluging [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/449944 (https://phabricator.wikimedia.org/T199747) [07:45:28] (PS2) Eileen: Update Omnimail silverpop plugin abd update the patch to reflect change [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/449944 (https://phabricator.wikimedia.org/T199747) [08:21:33] (PS3) Eileen: Update Omnimail silverpop plugin abd update the patch to reflect change [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/449944 (https://phabricator.wikimedia.org/T199747) [08:21:35] (PS1) Eileen: Update mrmarkfrench/silverpop-php-connector [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/449960 (https://phabricator.wikimedia.org/T199747) [08:21:37] (PS1) Eileen: Add Erase and Information request actions to Omnirecipient. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/449961 [08:21:45] (Abandoned) Eileen: Update Omnimail silverpop to manage set date to GMT [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/447975 (https://phabricator.wikimedia.org/T200240) (owner: Eileen) [08:22:03] (Abandoned) Eileen: WIP silverpop erasure [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/449937 (https://phabricator.wikimedia.org/T199747) (owner: Eileen) [13:52:16] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Civi: CID 12919617 not opening - https://phabricator.wikimedia.org/T201008 (MBeat33) [13:53:02] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Civi: CID 12919617 not opening - https://phabricator.wikimedia.org/T201008 (MBeat33) [14:00:35] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Civi: some CIDs not opening - https://phabricator.wikimedia.org/T201008 (MBeat33) [14:01:15] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Civi: some CIDs not opening - https://phabricator.wikimedia.org/T201008 (MBeat33) [14:28:23] Fundraising-Backlog, donate.wikimedia.org, FR-Email: Donatewiki: add device type to utm_campaign when utm_medium = email - https://phabricator.wikimedia.org/T164295 (Pcoombe) [14:28:40] Fundraising Tech Backlog, Fundraising-Backlog, donate.wikimedia.org: Look at using Lua for donatewiki - https://phabricator.wikimedia.org/T87669 (Pcoombe) [14:30:08] Wikimedia-Fundraising, donate.wikimedia.org: Translate donation support pages into Latin American Spanish - https://phabricator.wikimedia.org/T199685 (Pcoombe) [14:32:07] Fundraising Tech Backlog, Fundraising-Backlog, Wikimedia-Fundraising, Language-Team, donate.wikimedia.org: Exporting Fundraising translations from meta.wikimedia.org to donate.wikimedia.org should be more automated - https://phabricator.wikimedia.org/T111678 (Pcoombe) [14:37:10] (PS6) Mepps: Trying to simplify logic [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/446187 [14:45:08] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Civi: some CIDs not opening - https://phabricator.wikimedia.org/T201008 (cwdent) Yeah I can duplicate, it is running past the (newly doubled) 60s max execution time. My guess is something changed in the code that made this slower because we were gettin... [14:45:20] Fundraising-Backlog, Wikimedia-Fundraising, donate.wikimedia.org, wikimediafoundation.org: Move fundraising support pages to donate.wikimedia.org - https://phabricator.wikimedia.org/T189668 (Pcoombe) [14:45:38] Fundraising Sprint Karma chameleons hide amongst us, Fundraising Sprint Lactose is unusually tolerant, Fundraising Sprint Matt Damon to head up Space Force, Fundraising Sprint Naming Sprints Is Not Important, and 6 others: Help switch over foundation pages ... - https://phabricator.wikimedia.org/T193663 [14:46:04] Fundraising-Backlog, donate.wikimedia.org: Pare down list of extensions on Donatewiki - https://phabricator.wikimedia.org/T188522 (Pcoombe) [14:49:09] Fundraising-Backlog, fundraising-tech-ops, Epic: switch fundraising database replication from 'mixed' to 'row' - https://phabricator.wikimedia.org/T183140 (Jgreen) a:Jgreen [14:49:17] Fundraising-Backlog, fundraising-tech-ops: add primary keys or unique indexes to fundraising civicrm/drupal/pgehres database tables - https://phabricator.wikimedia.org/T176631 (Jgreen) a:Jgreen [17:23:30] fr-tech, where's the best place to find some audit files to try out the audit patches? [17:25:12] I can see a bunch in the tests/data directory of the wmf_audit module, are these verbatim ? [17:25:50] jgleeson: yeah, those are just anonymized versions of real audit files [17:26:08] awesome [17:26:16] Oh right, but I haven't added anything for the recurring Ingenico Connect, huh [17:26:27] jgleeson: there are some more samples in the SmashPig tests [17:26:49] Those tests are generally in each of the PaymentProvider subdirectories [17:50:20] Fundraising-Backlog, MediaWiki-extensions-CentralNotice: Banner previews occasionally fail to load - https://phabricator.wikimedia.org/T200853 (spatton) Hey @AndyRussG, it's happened with other banners too. I don't have a comprehensive list but I'd say ... half a dozen banner preview links in the last fe... [18:29:00] Fundraising Sprint Owls, Fundraising-Backlog, MW-1.32-release-notes (WMF-deploy-2018-08-07 (1.32.0-wmf.16)), Patch-For-Review: Adyen JCB 'invalid card' errors from donation form - https://phabricator.wikimedia.org/T200610 (MBeat33) Hey @Ejegg I'm a little unsure about time stamps across Civi, Ady... [19:44:18] (PS5) Ejegg: Components for new contact editor [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/443202 (owner: Eileen) [19:48:31] (CR) Ejegg: [C: 2] "Whew, there sure is a lot here! API v4 seems pretty powerful, and I like the Shoreditch look (when combined with Tivy). Doesn't look like " [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/443202 (owner: Eileen) [19:56:34] (Merged) jenkins-bot: Components for new contact editor [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/443202 (owner: Eileen) [19:58:22] (PS2) Ejegg: Enable new contact editor extensions [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/447563 (owner: Eileen) [19:58:35] (CR) Ejegg: [C: 2] Enable new contact editor extensions [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/447563 (owner: Eileen) [20:11:53] (Merged) jenkins-bot: Enable new contact editor extensions [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/447563 (owner: Eileen) [20:31:12] (CR) Ejegg: [C: 1] "Code looks good, works fine! Want to take it out of WIP?" [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/449379 (https://phabricator.wikimedia.org/T200227) (owner: Jgleeson) [20:33:59] ejegg, I left it WIP as I started working on some tests but never finished them [20:34:19] I spent a little bit of time thinking about mocking the google service, and got distracted [20:34:48] oh yeah, that sounds like that could be a real rabbit hole! [20:36:11] yeah.. [20:37:26] Well, I'm pretty satisfied with it [20:38:05] And seeing as how it's only coupled to our stuff via reading three db columns, test coverage on that particular part is low on my priority list [20:38:34] if you feel like un-WIPing it, I'd be happy to +2 so you can move on [20:41:23] thanks. I feel a bit uneasy leaving it without some type of test to confirm expected output vs the source data, in the event something changes in the future and it affects the rates data and associated expenses totals. It could be a hard one to pick up in the wild [20:44:34] maybe a quicker solution would be to write an integration test that hits the google sheets api to confirm what gets output in the spreadsheet in the total amount, matches what the raw source data would produce, that way skipping most of complicated stuff inbetween [20:45:15] jgleeson: hmm, I feel like it would be pretty clear for someone using the data if the wrong rates got into a column [20:49:53] ejegg, I'm also not 100% happy with how I'm lining up the currency headings with the currency rates, it's using array sorting (alphabetical) here https://gerrit.wikimedia.org/r/#/c/wikimedia/fundraising/crm/+/449379/4/sites/all/modules/exchange_rates/publishers/GoogleSheetsRatesPublisher.php@115 and I worry without some form of check, relying on sort to line up big data sets might trip up [20:51:15] I'd be interested to hear if you think there's a smarter way to do that? [20:51:50] ooh, that couldhmm, that COULD be an issue. lemme test what happens with some missing rates on one day [20:52:16] * ejegg tries to control his irc-stutter [20:52:21] lol [21:01:09] jgleeson: Ooh, you're right, that doesn't work when there are holes anywhere [21:01:48] (CR) Ejegg: [C: -1] "Needs to deal with holes in the data (exchange rate doesn't exist for a given currency for one day)" [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/449379 (https://phabricator.wikimedia.org/T200227) (owner: Jgleeson) [21:01:51] ahh I suspected it might need to change [21:02:33] So, I guess you'd want to start with an array where the top-level key is the currency [21:02:44] and values are an array of date->value [21:03:43] and then from that, map it to the spreadsheet format [21:03:51] right [21:03:54] yah [21:04:27] could loop over all date values seen, then over all currencies seen, and fill in cells [21:06:00] our internal logic for converting donations uses the closest previous rate for a currency if it doesn't find one for the specific day [21:06:11] e.g. weekends we don't get new values from OANDA [21:06:53] so you could fill in holes like that [21:07:51] If you look at OANDA's rates online, they seem to be constant from Fri-Sun from what I can see [21:07:58] actually that sounds like it would solve the empty rate problem also [21:08:15] also there's a chance it could be wrong [21:08:43] on days where interest rates changes :) [21:08:44] yeah, I guess instead of looping over all dates seen, you'd want to loop day by day over everything from the earliest date till the latest [21:09:17] right, 'cause we WILL have holes in our db tables every weekend [21:09:37] got it [21:09:47] ok I'll revisit it and tidy it up [21:09:47] cool cool [21:10:30] I'm fighting with my env at the moment, the civicrm test failures were preventing me doing a real test on your patches so I've been working through fixing it [21:11:23] latest issue is the include paths don't appear to be working, as the tests can't find the base classes [21:11:50] some of the tests* [21:11:53] jgleeson: oh, that should be set up in the phpunit bootstrap [21:12:03] wat, just some of the tests? [21:12:13] how are you running phpunit? [21:13:07] ./vendor/bin/phpunit --testdox --group WmfAudit [21:13:16] bootstrap is being hit as expected [21:13:25] weird, lemme try that again locally [21:13:52] also, gonna rebase across that big patch for the layout editor... [21:14:34] I had to also comment out org.wikimedia.omnimail/tests/phpunit/bootstrap.php as it was using civi cv:boot which didn't working being run under xdebug [21:15:09] although that's only a problem when debugging the tests [21:15:16] runs fine otherwise [21:15:37] ahh right, I had to do something weird to (i think) my php.ini to make that work [21:15:45] hmm, and it might not be working now [21:16:01] that would definitely be worth documenting if I can make it work again [21:16:43] ah man [21:16:44] (PS3) Ejegg: Move queue sending fns out of global scope [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/448808 (https://phabricator.wikimedia.org/T195337) [21:16:46] (PS3) Ejegg: Ingenico audit: deal with untokenized recurring. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/448820 (https://phabricator.wikimedia.org/T195337) [21:16:48] (PS2) Ejegg: Use SmashPig test queues in WmfAudit tests [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/449245 (https://phabricator.wikimedia.org/T172449) [21:16:53] sitting here with CNN on in the background [21:17:07] oh jeez, do I want to know? [21:17:35] it's still only August, can't be impeachment yet... [21:17:55] and apparently the director of the NSA has announced that he has been given authorisation to make "offensive cyber strikes" [21:18:01] oy [21:18:16] yeah nothing too major, just silly [21:18:26] well, IRC is pretty decentralized at least [21:18:59] could definitely see that leading to some nasty tit for tat escalation [21:20:05] crud, debug is hanging my tests too. Whatever I did must have been on an earlier PHP version's ini [21:20:14] i feel sorry for the government agencies world wide still way behind on IT setup just praying they don't get noticed [21:20:37] oh hey, that --testdox comman is pretty neat [21:20:40] *option [21:21:04] sure is [21:21:37] hmm, tests are passing for me tho [21:21:50] want to screenshare to show me how they're failing? [21:22:23] sure, I'll just get my headphones, brb [21:24:23] heading over to queenmary now [21:40:44] oops I didn't change my nick post lunch [22:10:13] (CR) Jgleeson: [V: 2 C: 2] "Looks good to me, works as expected and tests passing" [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/449245 (https://phabricator.wikimedia.org/T172449) (owner: Ejegg) [22:14:11] (CR) Jgleeson: [C: 2] Move queue sending fns out of global scope [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/448808 (https://phabricator.wikimedia.org/T195337) (owner: Ejegg) [22:15:28] ejegg, is there a corresponding Smashpig update to go with the patch which updates the version to 0.5.7? [22:16:31] (CR) Jgleeson: [C: 2] Ingenico audit: deal with untokenized recurring. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/448820 (https://phabricator.wikimedia.org/T195337) (owner: Ejegg) [22:19:53] (Merged) jenkins-bot: Move queue sending fns out of global scope [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/448808 (https://phabricator.wikimedia.org/T195337) (owner: Ejegg) [22:22:28] (Merged) jenkins-bot: Ingenico audit: deal with untokenized recurring. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/448820 (https://phabricator.wikimedia.org/T195337) (owner: Ejegg) [22:24:17] (Merged) jenkins-bot: Use SmashPig test queues in WmfAudit tests [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/449245 (https://phabricator.wikimedia.org/T172449) (owner: Ejegg) [22:29:36] have a good evening fr-tech! [22:29:41] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Civi: some CIDs not opening - https://phabricator.wikimedia.org/T201008 (MBeat33) This is not affecting a ton of records, but we do have several donor-initiated recurring donation updates on hold for the moment. [22:40:08] ejegg: got bogged down in a ton of conversations and docs. I wanted to bring this up. I'm not sure of how tough a fix this is but it's at least a minor blocker for DS. Sorry for the delay MBeat https://phabricator.wikimedia.org/T201008 [22:40:30] np [23:06:15] I’ll work on a patch for those slow loading contacts - I know what to do I’d just hoped to push it out until next week [23:06:34] ccogdill: did you have any feedback on testing deletes without doing it on the live silverpop database? [23:07:35] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Civi: some CIDs not opening - https://phabricator.wikimedia.org/T201008 (Eileenmcnaughton) Yeah I was hoping to push out the fix on this until next week but I know how to tackle this in code -there is a proposed patch I can trial & port [23:08:19] eileen: well if you have any input that would be great. Maybe it can be fixed before you get online in our monday (your tuesday) [23:08:54] there is a proposed patch upstream - I’ll take a look now - it won’t take that long [23:10:01] thanks! [23:10:13] gotta run for the day. see y'all [23:55:06] eileen are you working today? [23:55:25] no totally but am looking at that activity [23:55:34] although we could short term revert a fix too