[00:06:36] !log update civicrm from f78c894ba6686f0b512e8120eb75e928ef8c92fe to b26844d1bcd812af1a7e33e0cd330c7aad3c2364 [00:06:39] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log [00:07:34] I got a slight composer change in the autoloader files but I think that must be composer version related [00:08:39] Fundraising Sprint Waiting for Godot, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Blank address data being collected & stored as an address - https://phabricator.wikimedia.org/T153804#2891555 (Eileenmcnaughton) a:Eileenmcnaughton [00:12:06] Fundraising Sprint Value Subtracting, Fundraising Sprint Waiting for Godot, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, and 2 others: Fix Coinbase file to support importing UTM fields - https://phabricator.wikimedia.org/T153791#2915302 (Eileenmcnaughton) @CCogdill_WMF if you add these col... [03:24:41] Fundraising-Backlog: Spike: CentralNotice: Consider how to disable CN banners, or at least Fundraising banners, on FB's "Free Basics" service - https://phabricator.wikimedia.org/T154560#2915753 (AndyRussG) [03:25:17] Fundraising-Backlog, MediaWiki-extensions-CentralNotice: Spike: CentralNotice: Consider how to disable CN banners, or at least Fundraising banners, on FB's "Free Basics" service - https://phabricator.wikimedia.org/T154560#2915769 (AndyRussG) [03:36:46] Fundraising Sprint Waiting for Godot, Fundraising-Backlog, MediaWiki-extensions-CentralNotice: Spike: Impressions abnormally low for Ireland - https://phabricator.wikimedia.org/T152650#2915776 (AndyRussG) Found more details on this... - This is a proxy; the IP addresses are not those of readers per... [03:47:58] ejegg: hey! https://phabricator.wikimedia.org/T152650#2915776 [03:48:30] That table looks pretty definitive AndyRussG ! [03:49:24] So it was two different proxies, both taking advantage of Ireland's tax loopholes... [03:51:01] Heh yeah, more FB than the other... Dunno where else Opera proxies out, but I imagine that's just a small bit of it [03:51:16] * AndyRussG plays resounding music of definitiveness [03:51:32] a note of finality... [03:51:43] heh [03:52:06] Sure more satisfying than ending up saying, "well, it kinda looks like this, or like that, maybe a combination of these, oops ran out of time to look" [03:52:18] freal [03:52:52] Mmmm also now we know good places and ways to look for next time [03:53:12] I wonder what we'd find if we studied more what's up in California [03:53:16] thanks for writing up those queries [03:53:55] pleasure, it was infact pretty fun [03:54:39] 0.620781 impression rate for California on one day, probably something similar [03:54:58] (on mobile) [03:55:52] after taking googproxy into account? [03:56:10] Hmm not sure now [03:56:20] actually, I wouldn't be surprised if IORG had some CA endpoints too [03:56:39] heh good point! [04:03:17] Imma grep thru core + extensions to find how that header is set also [04:04:39] the Via header? [04:04:59] mebbe [04:07:18] so, another good final product of all this investigation would be an improvement to the queries they're using for campaign performance, to take all the pageviews from excluded users into account [04:08:07] yeah fer sures [04:08:23] We can definitely tune it much better [04:08:46] I'd really like to be able to get a flag for no-JS clients, too [04:09:07] totally [04:10:06] Hmmm $ grep -r IORG extensions/ returns naught [04:10:40] oh, the exact value... I dunno what else would care about that particular proxy [04:10:59] maybe the abuse filter extension would care about being from a proxy in general [04:11:10] But I mean, where's it being set? [04:11:27] Apparently it's an extension [04:11:29] https://github.com/wikimedia/mediawiki-extensions-XAnalytics/blob/master/XAnalytics.class.php [04:11:34] https://github.com/wikimedia/mediawiki-extensions-WikimediaEvents/blob/4c91f4b6f839735f768f81f922a0381cd1c1ead6/WikimediaEventsHooks.php [04:11:41] Oh wait, though, it's gotta be Varnish [04:11:52] Because, Varnish [04:12:12] https://developers.facebook.com/docs/internet-org/platform-technical-guidelines says that fb/i.org set some of the headers themselves [04:13:45] Right... but if we already have code detecting that, and munging up a unified "proxy" field... [04:14:23] ohhh, right, FB doesn't set the string 'IORG', they set Via: to Internet.org [04:14:31] and so we must be translating it someplace [04:14:37] yeah, varnish sounds most likely [04:15:02] yeah, I'm getting it from the x_analytics_map['proxy'] field in wmf.webrequests [04:15:34] aaarg where's that vlc when u need it [04:15:43] Did you find the code that processes the raw_requests table and writes webrequests? [04:16:08] Hmmm didn't look [04:16:21] That'd be where to put some no-JS code, I think [04:16:50] However, I think the x-analytics header is a header so it actually rides on all http requests. Maybe I'm wrong, though [04:16:59] https://www.mediawiki.org/wiki/Extension:XAnalytics [04:17:18] https://wikitech.wikimedia.org/wiki/X-Analytics [04:19:15] aha, got it, so it /is/ varnish who sets the 'proxy' field [04:21:24] must be, unless there's extra stuff added to the x_analytics in Hive that doesn't go out on the live http response [04:24:20] dunno what sense there'd be in sending a proxy flag on every request, infact [04:25:37] oooh foundit [04:26:11] the vcl? [04:27:40] https://github.com/wikimedia/operations-puppet/blob/2e2dd27d6e40886bcd048b675e5b4befc8777cee/modules/varnish/templates/analytics.inc.vcl.erb#L175-L180 [04:27:50] ahh [04:29:13] Apparently it's not easy to read http headers in JS, tho [04:29:39] AndyRussG: especially not if they're set between varnish and the webserver! [04:29:48] or the proxy and the webserver... [04:30:13] would have to be a server-side filter [04:30:25] ahhh right since we don't even run JS there most likely [04:30:54] * AndyRussG spritzes brain with caramelized onion powder [04:30:58] yeah, the JS could only know the request headers that the browser originally sends [04:31:09] owch! [04:32:07] apparently there are tricks to read http response headers in JS [04:32:29] do we set any of those things on the response? or just the request? [04:32:46] http://stackoverflow.com/questions/19440768/jquery-get-http-headers [04:32:58] oh, I see, it is setting resp.http.X-Analytics [04:33:04] it's all response header, heah [04:33:06] yeah [04:33:22] waaaaaait [04:33:31] do we even know if we're showing banners at all? [04:33:34] probably not even [04:33:56] aaaarg lemme check [04:36:00] oh derp, I guess I thought the vcl was setting things on the request for the web server to read. but if it's setting the analytics stuff on the response header, it must be visible to the JS somehow... or why would it bother to send and not just log? [04:37:33] yeah exactly the question [04:38:38] weird... [04:40:45] K running the BL query now [04:41:38] anyway, if we're already just not showing banners over this proxy, from our perspective, it's only an analytics issue... and a solved one, at that :) [04:42:18] Hmmm maybe the header is set in one of the further-back Varnish processes so that the outer Varnish processes can see it? [04:43:52] ejegg: yeah 0 bl requests w/ IORG proxy, at least in Ireland on Dec. 18 for mobile web [04:44:01] k, sounds good [04:44:12] though I do wonder how we're accomplishing that... [04:45:14] those useragents mostly should run JS [04:45:26] I think it's not us, but them (FB) [04:45:51] hmm, you think they specifically block our banner loader? [04:46:05] https://developers.facebook.com/docs/internet-org/platform-technical-guidelines [04:46:22] "In order to offer an experience that can work across devices, your service should remain functional and useful when JavaScript is disabled. This means that your content should not rely on JavaScript for any of the core user experiences" [04:46:41] maybe it's similar to googleweblight? [04:47:16] huh, you think they strip out JS? [04:47:57] could be, eh? [04:48:12] (also, "Cookies are supported. [04:48:14] ... The UA String from the original requestor is not altered by the Internet.org proxy.") [04:49:04] I wonder if they have a way to test... [04:49:13] hmm, would event reporting be a JS telltale? [04:49:25] EventLogging, rather [04:50:23] Check out also the "Testing" section [04:50:27] or maybe some of the load.php calls [04:51:03] hmmm [04:52:35] yeah, I guess they are saying that none of the proxied stuff gets JS: [04:52:38] As mentioned above, our web environment does not support JavaScript at this time [04:52:59] in the Analytics and Measurement section [04:53:16] Ah K [04:53:19] cool [04:53:39] so... if they DO start supporting it, we'll have to break it like we did for gwl [04:53:44] yeah nice that they stopped beating around the bush at least somewhere in the doc [04:53:55] yep [04:54:44] seems gwl is more sophisticated... or tries to be [04:55:00] k, it's the witching hour here. I'mma get some sleep! [04:55:17] nice sleuthing! [04:57:11] ejegg|away: cya, thx 4 ur help! [05:04:20] Fundraising Sprint Waiting for Godot, Fundraising-Backlog, MediaWiki-extensions-CentralNotice: Spike: Impressions abnormally low for Ireland - https://phabricator.wikimedia.org/T152650#2915831 (AndyRussG) Looking at data from BannerLoader requests, it seems that we may not be showing banners at all o... [05:08:10] Fundraising-Backlog, MediaWiki-extensions-CentralNotice: Spike: CentralNotice: Consider how to disable CN banners, or at least Fundraising banners, on FB's "Free Basics" service - https://phabricator.wikimedia.org/T154560#2915832 (AndyRussG) Actually, it seems this may not be an issue, since users over t... [16:07:46] o/ AndyRussG [16:08:12] I thought you might like this, found a useful TeX package: https://github.com/adamwight/ores-diagrams/ [16:09:54] I'm real happy about the minimalish source form, even the "matrix" layout is less annoying than I expected... [16:33:23] awight: hey cool, thanks!!!! [16:33:49] the cps way! [16:34:10] I had lots of fun w/ Hive and plotting for mobile outage in Ireland task [16:35:53] gonna post some queries I did on mw.org soooon (since a bunch of the flailing around wasn't relevant to report on the task) [17:48:43] fundraising-tech-ops, Operations, ops-eqiad: Degraded raid on barium - https://phabricator.wikimedia.org/T154039#2916946 (Jgreen) I ~think~ both of the original 3TB disks have failed. I was able to confirm that we replaced the correct disk from the before+after megacli reports, but the hardware RAID... [17:49:43] fundraising-tech-ops, Operations, ops-eqiad: Degraded raid on barium - https://phabricator.wikimedia.org/T154039#2916960 (Jgreen) p:Triage>Normal changing status to normal, the task is now "remove both 3TB disks from barium" [17:56:16] AndyRussG|errnd: the CPS way is pretty inspiring, I won't lie! [18:00:30] fr-tech: That's life. [18:00:30] What's life? [18:00:30] A magazine. [18:00:30] How much does it cost? [18:00:30] Two-fifty. [18:00:31] I only have a dollar. [18:00:31] That's life. [18:00:32] -- discuss. [18:02:29] Fundraising-Backlog, FR-Worldpay: Evaluate if we need to do anything for worldpay update - https://phabricator.wikimedia.org/T129122#2917014 (Ejegg) Open>declined [18:02:41] Fundraising-Backlog, Epic: [epic] Make WorldPay more robust - https://phabricator.wikimedia.org/T77909#2917016 (Ejegg) [18:02:43] Fundraising-Backlog, Recurring-Donations: Account Updater via WorldPay - https://phabricator.wikimedia.org/T91860#2917015 (Ejegg) Open>declined [18:02:50] Fundraising-Backlog, FR-Worldpay: Failover Worldpay API urls - https://phabricator.wikimedia.org/T116195#2917017 (Ejegg) Open>declined [18:03:06] Fundraising-Backlog: Worldpay: donors on Firefox receiving weird SSL error - https://phabricator.wikimedia.org/T91694#2917019 (Ejegg) Open>declined [18:03:16] Fundraising-Backlog: Fix WP mobile forms - https://phabricator.wikimedia.org/T85583#2917043 (Ejegg) [18:03:18] Fundraising-Backlog, WMF-Design, Design: Polish : Credit card input form should reflect organization of credit card - https://phabricator.wikimedia.org/T1189#2917044 (Ejegg) [18:04:24] Fundraising-Backlog, FR-Worldpay, Epic: [EPIC] Worldpay as english backup processor? - https://phabricator.wikimedia.org/T114701#2917049 (Ejegg) Open>declined [18:04:38] Fundraising-Backlog, Patch-For-Review: Unbreak WMF-hosted Worldpay workflow - https://phabricator.wikimedia.org/T112665#2917056 (Ejegg) [18:04:41] Fundraising-Backlog, Easy: WPUS: TransDetVer2 audit parsing is broken - https://phabricator.wikimedia.org/T113787#2917054 (Ejegg) Open>declined [18:04:46] Fundraising-Backlog, FR-Worldpay, Epic: [EPIC] Worldpay as english backup processor? - https://phabricator.wikimedia.org/T114701#1703392 (Ejegg) [18:05:03] Fundraising-Backlog, Epic: [EPIC] Worldpay France post launch - https://phabricator.wikimedia.org/T114682#2917074 (Ejegg) [18:05:05] Fundraising-Backlog, FR-Worldpay, MediaWiki-extensions-DonationInterface: Hebrew or other non-Latin characters not making it into Worldpay donations - https://phabricator.wikimedia.org/T114000#2917073 (Ejegg) Open>declined [18:05:12] Fundraising-Backlog, Epic: [epic] Make WorldPay more robust - https://phabricator.wikimedia.org/T77909#2917075 (Ejegg) Open>declined [18:05:27] Fundraising-Backlog: Should we remove name fields from WMF hosted part of WorldPay ESOP form? - https://phabricator.wikimedia.org/T113303#2917077 (Ejegg) Open>declined [18:05:37] Fundraising-Backlog, FR-Worldpay, Epic: [EPIC] Worldpay as english backup processor? - https://phabricator.wikimedia.org/T114701#1703392 (Ejegg) [18:05:47] Fundraising-Backlog: Make automated refunds possible in Worldpay - https://phabricator.wikimedia.org/T89046#2917080 (Ejegg) Open>declined [18:05:49] Fundraising-Backlog, Epic: [epic] Make WorldPay more robust - https://phabricator.wikimedia.org/T77909#831551 (Ejegg) [18:06:02] Fundraising-Backlog, Epic: [EPIC] Worldpay France post launch - https://phabricator.wikimedia.org/T114682#1702919 (Ejegg) [18:06:04] Fundraising-Backlog: EXTERNAL: CVV error code on WorldPay form - https://phabricator.wikimedia.org/T114677#2917083 (Ejegg) Open>declined [18:06:12] Fundraising-Backlog, Epic: [epic] Make WorldPay more robust - https://phabricator.wikimedia.org/T77909#831551 (Ejegg) [18:06:14] Fundraising-Backlog, § Fundraising Sprint Abba: Make WorldPay NZD work - https://phabricator.wikimedia.org/T86097#2917085 (Ejegg) Open>declined [18:06:38] Fundraising-Backlog, Recurring-Donations: WorldPay Recurring - https://phabricator.wikimedia.org/T103448#2917091 (Ejegg) Open>declined [18:06:44] Fundraising-Backlog: Handle "QueryTokenData failed" messages from Worldpay - https://phabricator.wikimedia.org/T116712#2917093 (Ejegg) Open>declined [18:06:56] Fundraising Tech Backlog, Fundraising-Backlog: Bug: WorldPay audit processing needs more error checking - https://phabricator.wikimedia.org/T98802#2917094 (Ejegg) Open>declined [18:07:06] Fundraising-Backlog, Epic: [EPIC] Worldpay France post launch - https://phabricator.wikimedia.org/T114682#2917096 (Ejegg) Open>declined [18:07:35] Fundraising-Backlog, Epic: [epic] Make WorldPay more robust - https://phabricator.wikimedia.org/T77909#2917098 (Ejegg) [18:07:37] Fundraising-Backlog, § Fundraising Sprint Abba: Fix WorldPay in GB - https://phabricator.wikimedia.org/T86098#2917097 (Ejegg) Open>declined [18:07:47] Fundraising-Backlog, Patch-For-Review: Unbreak WMF-hosted Worldpay workflow - https://phabricator.wikimedia.org/T112665#2917100 (Ejegg) Open>declined [18:08:13] Fundraising-Backlog: Fix WP mobile forms - https://phabricator.wikimedia.org/T85583#2917103 (Ejegg) Open>declined [18:08:15] Fundraising-Backlog, Epic: [epic] Make WorldPay more robust - https://phabricator.wikimedia.org/T77909#831551 (Ejegg) [18:08:41] Fundraising-Backlog, FR-Worldpay: Debugging: sent WorldPay the "stringin" logs for a transaction Anne made - https://phabricator.wikimedia.org/T122866#2917108 (Ejegg) Open>declined [18:10:02] Fundraising-Backlog, MediaWiki-extensions-DonationInterface: Expiration date error message is wrong when date < now - https://phabricator.wikimedia.org/T89388#2917120 (Ejegg) Open>declined [18:13:56] fr-tech: anything for Scrum of Scrums? [18:14:05] Also, i'm in fr-tech-talk for the next 15 minutes [18:18:48] (CR) Ejegg: [C: 2] "Self-merging .gitignore update" [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/329509 (owner: Ejegg) [18:20:15] (Merged) jenkins-bot: Revert on deployment: gitignore vendor directory [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/329509 (owner: Ejegg) [18:29:26] !log enabled payment processor audit parser jobs [18:29:28] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log [19:16:04] Fundraising Sprint Waiting for Godot, Fundraising-Backlog, MediaWiki-extensions-CentralNotice: Spike: Impressions abnormally low for Ireland - https://phabricator.wikimedia.org/T152650#2917326 (bd808) >>! In T152650#2915776, @AndyRussG wrote: > Finally bit of follow-up: the original users' IP address... [19:31:00] Fundraising-Backlog, fundraising-tech-ops: migrate fundraising.wikimedia.org off of the civicrm webserver - https://phabricator.wikimedia.org/T152106#2917398 (Jgreen) [19:42:43] Fundraising-Backlog, fundraising-tech-ops: Deprecate and remove twig and phpmailer projects - https://phabricator.wikimedia.org/T141914#2917437 (Jgreen) Open>Resolved done including deployed code removal [19:45:51] (PS1) Ejegg: Little cleanups to large donation notifier [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/330457 [19:51:12] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: add link to large donation bot emails - https://phabricator.wikimedia.org/T153020#2866675 (Ejegg) Looks like there's already a link to the contribution itself. We need a second link directly to the contact record? [20:09:28] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, WorkType-NewFunctionality: Create an import method for matching gifts and payroll deductions - https://phabricator.wikimedia.org/T115044#2917568 (CaitVirtue) @DStrine Can we bump this back up the priority queue? @RLewis and @LeanneS have the detail... [20:22:00] (PS1) Georggi199: Update Maintenance scripts to use $this->requireExtension() [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/330465 (https://phabricator.wikimedia.org/T152139) [20:26:20] Fundraising Sprint Waiting for Godot, Fundraising-Backlog, MediaWiki-extensions-CentralNotice, MW-1.29-release-notes, and 5 others: Spurious Amazon clicks / Banners on googleweblight.com - https://phabricator.wikimedia.org/T152602#2917669 (AndyRussG) >>! In T152602#2878773, @Pcoombe wrote: > @And... [20:35:00] Fundraising Sprint Waiting for Godot, Fundraising-Backlog, MediaWiki-extensions-CentralNotice, MW-1.29-release-notes, and 5 others: Spurious Amazon clicks / Banners on googleweblight.com - https://phabricator.wikimedia.org/T152602#2917681 (AndyRussG) Looking at beacon/impression data from Decembe... [20:35:21] Fundraising Sprint Waiting for Godot, Fundraising-Backlog, MediaWiki-extensions-CentralNotice, MW-1.29-release-notes, and 5 others: Spurious Amazon clicks / Banners on googleweblight.com - https://phabricator.wikimedia.org/T152602#2917682 (AndyRussG) Open>Resolved [20:58:58] (CR) Cdentinger: [C: 2] Fix JsonException extends statement [wikimedia/fundraising/php-queue] - https://gerrit.wikimedia.org/r/330256 (owner: Ejegg) [20:59:52] (Merged) jenkins-bot: Fix JsonException extends statement [wikimedia/fundraising/php-queue] - https://gerrit.wikimedia.org/r/330256 (owner: Ejegg) [21:00:29] (CR) Cdentinger: [C: 2] Decoding null to null is not an error [wikimedia/fundraising/php-queue] - https://gerrit.wikimedia.org/r/329531 (owner: Ejegg) [21:01:15] (Merged) jenkins-bot: Decoding null to null is not an error [wikimedia/fundraising/php-queue] - https://gerrit.wikimedia.org/r/329531 (owner: Ejegg) [21:03:38] (PS4) Cdentinger: WIP: Process payment before popping out of iframe [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/328725 (https://phabricator.wikimedia.org/T153972) [21:15:52] grabbing a quick bite [21:35:48] cwd think it will be possible to consolidate the resultswitcher code as part of that ticket? [21:36:05] ejegg: i was just cracking that open again [21:36:20] my monitor died appears to have died :-\ [21:36:26] ah jeez [21:36:39] on the company laptop? [21:37:34] nah just an external monitor [21:37:48] ah, productivity hit, huh? [21:38:12] oh hey, thanks for the php-queue reviews. I'll try updating the DonationInterface composer libs [21:38:56] you bet! good to tighten up those couple places [21:39:02] ah it was just the cheapo power strip [21:39:23] ah, nice [21:39:56] so are you thinking we combine some gateways' result switcher pages? [21:40:17] cwd yep! I think all but ingenico use the common logic [21:40:51] will ingenico be the only one to process before pop-out or should we try that for others? [21:41:00] in GatewayPage::handleResultRequest [21:41:08] we should do that for all of em! [21:41:38] maybe we should try just one out first in case there is unexpected nonsense? [21:42:25] ehhh, i think it would be more of a pain to make the code change in two places [21:42:51] maybe one commit to merge them, then another to flip the order of the pop-out [21:43:16] make ingenico use the normal resultswitcher? [21:43:23] or does the logic live in gatewaypage? [21:43:35] yeah, make ingenico use the normal one [21:43:43] lemme see [21:44:23] ok, so most result switchers just do a tiny bit of setup (gateway adapter class and maybe set the active transaction name), then call handleResultRequest [21:45:53] ejegg: i see a relevant comment here https://github.com/wikimedia/mediawiki-extensions-DonationInterface/blob/master/globalcollect_gateway/globalcollect_resultswitcher.body.php#L174 [21:46:30] yep, the plan was always to merge them [21:46:39] but of course something else came up [21:47:27] k, there's a bunch of logic in GC [21:47:42] 's resultswitcher page that more properly belongs in the adapter [21:48:37] the generic one calls processResponse with an array of all the querystring and post variables [21:50:08] ugh, that function is totally used for multiple overlapping things [21:50:15] wellllll [21:50:17] processResponse? [21:50:20] yeah [21:50:30] hrm [21:50:53] it's used to examine API responses, and to do the needful with the user returning from the processor [21:51:08] ah yeah i see that big switch [21:51:29] So... let's say the adapters implement a processDonorReturn instead [21:51:40] and that takes all the vars from the request [21:52:18] I can start pulling that out of processResponse for the other gateways [21:53:07] will that be the part that does the charge? [21:53:22] yep! [21:53:37] great [21:54:17] k, want me to help with the other gateways while you write the implementation for ingenico? [21:54:39] that would be great [21:54:43] cool, will do! [21:54:55] so basically the resultswitcher needs to call processResponse? [21:55:14] or processDonorReturn? [22:04:17] cwd yep, I'll make it call processDonorReturn [22:06:15] (PS1) Ejegg: WIP less overloaded processResponse [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/330580 [22:06:21] cwd that's the basic idea ^^^ [22:06:34] needs paypal EC tweezed out [22:07:23] excellent, thanks [22:08:29] (CR) jerkins-bot: [V: -1] WIP less overloaded processResponse [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/330580 (owner: Ejegg) [22:16:44] (PS2) Ejegg: WIP less overloaded processResponse [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/330580 [22:17:47] ejegg: so the adapters shouldn't have custom processResponse functions anymore? [22:19:00] (CR) jerkins-bot: [V: -1] WIP less overloaded processResponse [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/330580 (owner: Ejegg) [22:24:40] (PS3) Ejegg: Less overloaded processResponse [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/330580 [22:25:00] that /might/ actually be all we need ^^ [22:25:27] cwd oh, most of the adapters will still need their own processResponse logic [22:26:10] will that also need to get called from the resultswitcher? [22:26:22] nah, that was the freak case [22:26:38] it should now only be called when we're looking at a real API response [22:28:05] ejegg: i notice it doesn't get called here anymore https://gerrit.wikimedia.org/r/#/c/330580/3/gateway_common/GatewayPage.php [22:28:56] (PS4) Ejegg: Less overloaded processResponse [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/330580 [22:29:36] cwd yep, it now only gets called after the API call in do_transaction_internal [22:30:07] k, I'm going to try to smoke test that a bit [22:42:59] (PS1) Ejegg: Erase Stomp [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/330591 [22:44:20] (PS2) Ejegg: Erase Stomp [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/330591 [22:45:56] (CR) jerkins-bot: [V: -1] Erase Stomp [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/330591 (owner: Ejegg) [22:48:32] (PS3) Ejegg: Erase Stomp [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/330591 [22:50:20] AndyRussG + awight do either of you know why the banner cache is so much longer on mobile compared with desktop [22:58:22] ejegg: will processDonorReturn in some way call processResponse? [23:00:45] (PS4) Ejegg: Erase Stomp [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/330591 [23:00:59] cwd sometimes it will, depends on what it needs to do [23:01:12] though... only indirectly [23:01:20] yeah [23:01:26] but in the case of we want to take money? [23:01:29] if processDonorResponse calls do_transaction at all [23:01:45] it will be down the call stack somwhere [23:02:08] yah. for ingenico, I think processDonorResponse just needs to do_transaction( 'confirm_creditcard' ) [23:02:37] plus whatever duplication-guard code that's currently in the globalcollect resultswitcher [23:03:17] Seddon: is it now? [23:03:45] how's that manifesting itself? [23:07:25] Seddon: It just seems that changes I make on a banner for desktop propagate through fairly quickly. But for mobile it's like I'm having to wait the full 10 minutes [23:07:42] cwd I think we can get rid of that guard on 'requested order ID not present in the session' [23:08:11] cwd since those donations will be pushed through by the orphan rectifier, we don't WANT them to be shown a fail page [23:08:30] ejegg: sorry added my name above not yours ^ [23:08:40] ejegg: are those the double charges? [23:09:11] Seddon: I'm not seeing anything in the CentralNotice code that would do that. I wonder if it's happening globally [23:09:21] Seddon: ah, also, are you logged in on mobile? [23:10:00] cwd yeah, that's a possible source of double donations [23:10:36] ejegg: do we want to still log there? [23:11:23] ejegg: I would be yeah [23:11:50] cwd sure, might as well. But move that part into the processDonorReturn, so we can clear all the custom logic out of GC resultswitcher's handleRequest function [23:12:27] sounds good [23:13:02] annnnd the wiki is down [23:13:08] oh snap [23:13:28] yikes [23:13:33] enwiki looks ok for me... meta? [23:13:59] oho, that was just cached [23:14:08] login link shows the error [23:14:25] "Argument 1 passed to __invoke() must be an instance of array, string given" [23:15:07] Roan's reverting [23:16:19] woot, fixed [23:17:29] hah, I wonder if we got any payments traffic from that donate link in the error page [23:17:52] ...needs utm_ parameters [23:18:42] enwiki looks fine [23:18:49] Ah yeah I see reverted [23:19:02] heh [23:19:13] "we're drowning... help us!" [23:20:15] Seddon: IIRC it's not that it's exactly 10 minutes following an update that you'll see the changes, but rather maximum 10 minutes. As in, the data goes with JS updates that are refreshed on a 10-minute cycle [23:20:47] So you might make one change and it'd just be on the cusp of a cycle and you'd see it right away, and another you might make right after a refresh [23:20:49] stomp dependency eradicated from SmashPig: https://gerrit.wikimedia.org/r/330591 (pre-req to getting it out of crm / di vendor dirs) [23:20:52] Not totally sure, tho [23:21:43] ejegg: FWIW, ^ for RL updates, logged-in or not shouldn't change anything, I think [23:22:19] AndyRussG: oh huh [23:22:52] Yeah pretty sure loggedins are still cached the same amount for that [23:22:55] Seddon do you mean using the ?banner= parameter [23:23:13] Ah yeah in that case it'd make a difference [23:24:03] ejegg: Seddon: ah yes for banner _content_ it is faster for loggedins (hits php), for banner settings it's the 10-min dance for all [23:24:11] sorry /me learns to read ;p [23:24:25] though, Seddon said he's logged in on mobile too [23:29:24] (PS5) Ejegg: Erase Stomp [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/330591 [23:30:58] (PS1) Ejegg: Update composer dependencies [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/330599 [23:39:39] ejegg: sounds like we are going to get snowed in shortly so i need to go chop some fire wood, back later on and will finish this [23:40:30] cwd ok, i'll be off for a bit too but will be back on late