[00:02:07] Fundraising Sprint Unbreaking Now, Fundraising Sprint Value Subtracting, Fundraising-Analysis, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Civi: Contribution report: add column for preferred language - https://phabricator.wikimedia.org/T146942#2819589 (Ejegg) Open>Resolved [00:02:35] Fundraising Sprint Value Subtracting, Fundraising-Backlog, Patch-For-Review: Mobile web form style fixes - https://phabricator.wikimedia.org/T149249#2819592 (Ejegg) Open>Resolved [00:02:46] Fundraising Sprint Value Subtracting, Fundraising-Backlog, FR-Paypal, Patch-For-Review, Unplanned-Sprint-Work: Paypal audit parser sends duplicate messages - https://phabricator.wikimedia.org/T150998#2819593 (Ejegg) Open>Resolved [00:02:55] Fundraising Sprint Value Subtracting, Fundraising-Backlog, MediaWiki-extensions-DonationInterface, Patch-For-Review, Unplanned-Sprint-Work: Empty zip code error message missing - https://phabricator.wikimedia.org/T151416#2819594 (Ejegg) Open>Resolved [00:03:07] Fundraising Sprint Value Subtracting, Fundraising-Backlog, FR-Paypal, Patch-For-Review, Unplanned-Sprint-Work: Paypal audit parser sends duplicate messages - https://phabricator.wikimedia.org/T150998#2804200 (awight) Looks like this patch only did refunds and not subscr_cancel. [00:03:17] Fundraising Sprint Value Subtracting, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, Patch-For-Review, Unplanned-Sprint-Work: Donation import falling behind - https://phabricator.wikimedia.org/T151068#2819597 (Ejegg) Open>Resolved [00:04:28] Fundraising Sprint Value Subtracting, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, FR-2016-17-Q2-Bugs, Patch-For-Review: Wrong date encoding fails some donation messages - https://phabricator.wikimedia.org/T147603#2819611 (Ejegg) Open>Resolved [00:05:37] Fundraising Sprint Value Subtracting, Fundraising Sprint W 2016, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, FR-2016-17-Q2-Bugs: Engage import failing to import certain significant fields - https://phabricator.wikimedia.org/T146295#2819641 (DStrine) [00:05:39] Fundraising Sprint Testing on Production, Fundraising Sprint Unbreaking Now, Fundraising Sprint Value Subtracting, Fundraising Sprint W 2016, and 5 others: CentralNotice: Relay banner loading issues in beacon/impression - https://phabricator.wikimedia.org/T149107#2819639 (DStrine) [00:05:41] Fundraising Sprint Testing on Production, Fundraising Sprint Unbreaking Now, Fundraising Sprint Value Subtracting, Fundraising Sprint W 2016, and 3 others: Civi: restore the 'unsubscribe from spam' option to Main menu - https://phabricator.wikimedia.org/T147571#2819640 (DStrine) [00:05:44] Fundraising Sprint Rocket Surgery 2016, Fundraising Sprint Stirring The Pot, Fundraising Sprint Testing on Production, Fundraising Sprint Unbreaking Now, and 4 others: Impressions slow to update on jaJP dsk campaign - https://phabricator.wikimedia.org/T145446#2819645 (DStrine) [00:05:46] Fundraising Sprint Qwerty Thwacking, Fundraising Sprint Rocket Surgery 2016, Fundraising Sprint Stirring The Pot, Fundraising Sprint Testing on Production, and 7 others: Investigate the discrepancy between pageview counts and banner impressions for ... - https://phabricator.wikimedia.org/T145565#2819643 [00:05:48] Fundraising Sprint Value Subtracting, Fundraising Sprint W 2016, Fundraising-Backlog, MediaWiki-extensions-CentralNotice, and 2 others: Spike: Prioritized checklist of pre-December CentralNotice and related essentials - https://phabricator.wikimedia.org/T141918#2819648 (DStrine) [00:05:51] Fundraising Sprint Rocket Surgery 2016, Fundraising Sprint Stirring The Pot, Fundraising Sprint Testing on Production, Fundraising Sprint Unbreaking Now, and 7 others: Banner not showing up on site - https://phabricator.wikimedia.org/T144952#2819646 (DStrine) [00:05:53] Fundraising Sprint Asbestos Removal 2016, Fundraising Sprint Bloodletting 2016, Fundraising Sprint Testing on Production, Fundraising Sprint Unbreaking Now, and 10 others: [Epic] Do not show donation form error message: "No processors available". Fi... - https://phabricator.wikimedia.org/T117872#2819649 [00:30:54] happy holiday everyone [00:33:19] have a nice drive! [00:45:47] (CR) Ejegg: [C: 2] Re-apply WMF patches [wikimedia/fundraising/crm/drupal] - https://gerrit.wikimedia.org/r/322823 (owner: Eileen) [01:02:46] fr-tech urgent, quoting bblack: [01:02:48] 14:59 AndyRussG|bassoo: Special:Banner is currently exempted from the varnish code that normally re-sets the user-facing Cache-Control to be 0s/no-cache for wiki pages. That exemption is old, I'm pretty sure it pre-dates me. But in any case that means your 10 minute TTLs are not just for varnish, they're also in browser caches. [01:02:50] 14:59 <<--> ankry (~ankry@2001:4070:10:4800:1:beef:15:dead) has left #wikimedia-operations [01:02:52] 14:59 AndyRussG|bassoo: unless we change that, anything we do in varnish to invalidate a banner is only going to affect fresh UAs, not ones that have already cached it and will keep it another few minutes. [01:02:54] 15:02 AndyRussG|bassoo: that issue aside, we should be able to rig up something using mwScript to purge the banner-related URLs on demand when warranted, for now. [01:03:09] wrt client-side caching [01:03:16] anyway, I think it's urgent! [01:03:22] oh, whoa [01:03:51] wait, that's Special:Banner, not Special:BannerLoader? [01:04:00] Ah huh [01:04:02] weird [01:04:06] We're directly outputting the cache control header on BannerLoader [01:04:31] and when I checked yesterday, the max-age was 0 (and s-max-age was set appropriately) [01:05:00] There is no Special:Banner [01:05:12] rather Special:CentralNoticeBanners [01:05:38] You need to check it as an anon, on the live site [01:07:37] (PS3) Ejegg: WIP rename 'zip' to 'postal_code' [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/320267 [01:09:02] AndyRussG: but that's an admin page, what do we care about anons looking at a 10 minute old version? [01:09:29] (CR) jenkins-bot: [V: -1] WIP rename 'zip' to 'postal_code' [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/320267 (owner: Ejegg) [01:20:38] (CR) Eileen: "ejegg - thanks for that - it needs the unpatched version approved in order to merge. I believe the test failure won't matter as this one p" [wikimedia/fundraising/crm/drupal] - https://gerrit.wikimedia.org/r/322823 (owner: Eileen) [01:24:33] AndyRussG: I'm thinking that's not too troubling. Going to head out for a while, but i'll check in later in case you think it's a huge problem. [01:26:22] ejegg: I think he meant the SpecialBannerLoader [01:26:41] which would be an issue if we need to update a banner that people can get more than once [01:28:20] AndyRussG: Here's what I get: cache-control:public, s-maxage=600, max-age=0 [01:28:27] that's anonymous on the live site [01:28:34] Hmmm [01:28:38] And what does that mean [01:28:44] * AndyRussG hides ignorance under carpet [01:29:00] max-age is for private (ie browser) caches [01:29:11] s-maxage is for shared caches (ie varnish) [01:29:26] and that's what we're outputtingg manually with those header() calls [01:29:43] so the browser will always re-request [01:30:38] http://stackoverflow.com/questions/3492319/private-vs-public-in-cache-control [01:31:21] ejegg: I have bblack on this right now in #wikimedia-operations, pls allow me to quote u there :) [01:31:33] yep, so it means that shared caches are allowed to store it [01:31:36] go ahead! [01:31:50] and those shared caches don't have to revalidate for 600 sec [01:32:01] but private caches should revalidate every time [01:32:19] 19:29 AndyRussG: I meant all URL's matching Special:Banner.* [01:32:21] 19:29 AndyRussG: in the code it's: if (req.url !~ "^/(wiki/|(w/index\.php)?\?title=)Special:Banner") { [01:32:23] 19:30 (which excludes those URLs from having the appserver's Cache-Control header replaced by "private, s-maxage=0, max-age=0, must-revalidate" for user-agent consumption, which is what we do for wiki articles to avoid client-side caching) [01:32:25] 19:31 it's functionally easy to remove or modify that exclusion, but I have to wonder why we made it in the first place... [17:36:08] Fundraising Sprint Asbestos Removal 2016, Wikimedia-Fundraising: Other amount in WMF donation form: error message unclear - https://phabricator.wikimedia.org/T118741#2821574 (Pcoombe) Open>Resolved This was due to particularly annoying Safari behaviour. When is used, on mobi... [18:00:03] fr-tech: "That's no answer," Job said, "And for someone who's supposed to be [18:00:03] omnipotent, let me tell you `tabernacle' has only one l." [18:00:03] -- Woody Allen, "Without Feathers" [18:00:03] -- discuss. [18:38:27] AndyRussG: I'm late to the party, but I think the Varnish exclusion might be harmless [18:38:44] does bblack know that we're outputting "max-age: 0" ourselves? [18:39:11] That term should prevent browsers from caching [18:41:36] In case you were looking for the source, it's operations-puppet/modules/varnish/templates/text-frontend.inc.vcl.erb [19:08:35] awight|afk: hi! thx :) u saw the backscroll in operations [19:08:37] ? [19:09:12] K good to hear :) [19:09:28] Hmmm mebbe he didn't notice that... [19:09:45] I didn't yet quite understand the cache params, hafta look that up [19:10:10] On the plus side, I think I know why our beacon/impression warning about the missing banner i18n messages wasn't doing squat... [20:13:26] AndyRussG: ooh? what's that? [20:13:40] sorry about my spam on that ticket [20:13:49] I misunderstood the issue, due to not reading through the comments [20:14:18] eventually did comprehend that the missing banner message might be the *only* exception not being logged using the neat new system [22:16:55] awight|afk: it's that it's unlikely for a new banner be really served to a campaign within the first 1-2 minutes of its creation, because 10 minutes RL lag. I think your URL for triggering on prod is a great test btw!