[00:20:48] Fundraising-Backlog, MediaWiki-extensions-DonationInterface: Frontend maintenance flag could be gentler - https://phabricator.wikimedia.org/T133131#2221444 (awight) [00:27:46] Fundraising-Backlog, Documentation, FR-ActiveMQ: Add a column to queue component documentation: the message format - https://phabricator.wikimedia.org/T133132#2221456 (awight) [00:28:02] Fundraising-Backlog, Documentation, FR-ActiveMQ: Add a column to queue component documentation: the message format - https://phabricator.wikimedia.org/T133132#2221470 (awight) [02:03:49] Fundraising Sprint Hermit Crab Husbandry, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Investigation: dedupe exact matches - https://phabricator.wikimedia.org/T132396#2221609 (Eileenmcnaughton) I thought I would try deduping a small group through the uI first to see how that looks. Sadly when... [02:06:34] Fundraising Sprint Hermit Crab Husbandry, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Investigation: dedupe exact matches - https://phabricator.wikimedia.org/T132396#2221611 (Eileenmcnaughton) By comparison this query is almost instantaneous - ie. replacing 'OR' with 'Union' SELECT t1.contac... [04:44:39] Fundraising Sprint Hermit Crab Husbandry, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Investigation: dedupe exact matches - https://phabricator.wikimedia.org/T132396#2221660 (Eileenmcnaughton) So here are some steps so far that I have identified 1) get some sample contacts & use the contactm... [05:03:19] Fundraising Sprint Hermit Crab Husbandry, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Investigation: dedupe exact matches - https://phabricator.wikimedia.org/T132396#2221667 (Eileenmcnaughton) Also, I kinda managed to get a batch dedupe to run - but I was informed some failed to merge with c... [06:20:53] Fundraising Sprint N*E*R*D, Fundraising Sprint ODB, Fundraising Sprint Snoop (Dogg|Lion), Fundraising-Backlog, and 3 others: Publishing translations for central notice banners fails - https://phabricator.wikimedia.org/T104774#1426665 (Nemo_bis) I doubt this would be helped by T116235. This is typ... [06:25:16] Fundraising-Backlog, MediaWiki-extensions-CentralNotice, Epic, I18n: [Epic] Use translatable pages for banner content - https://phabricator.wikimedia.org/T116235#1744136 (Nemo_bis) I'm very surprised by this proposal, I hope you'll investigate the design thoroughly before starting implementation.... [09:08:53] Fundraising Sprint N*E*R*D, Fundraising Sprint ODB, Fundraising Sprint Snoop (Dogg|Lion), Fundraising-Backlog, and 3 others: Publishing translations for central notice banners fails - https://phabricator.wikimedia.org/T104774#2221998 (Nikerabbit) >>! In T104774#2221783, @Nemo_bis wrote: > I doubt... [13:01:26] Fundraising Sprint Snoop (Dogg|Lion), Fundraising-Backlog, MediaWiki-extensions-CentralNotice, MediaWiki-extensions-Translate: Central Notice message groups are slow to index - https://phabricator.wikimedia.org/T111189#2223101 (Nikerabbit) a:Nikerabbit>None I am not working on this curren... [13:12:02] Fundraising Sprint Ghostbusting , Fundraising Sprint Hermit Crab Husbandry, Fundraising-Backlog, MediaWiki-extensions-CentralNotice: CentralNotice: Make a plan for moving stuff out of cookies - https://phabricator.wikimedia.org/T131319#2223230 (AndyRussG) Main questions that I hope we can answer... [15:33:29] /nick cwd [15:33:45] :| [16:05:59] cwd: I've been having weird thoughts about the queue situation. Here's my sketchy diagram so far: https://www.mediawiki.org/wiki/File:Fundraising_queues_class_diagram.svg [16:06:44] sweet [16:07:00] I think I proved to myself that FifoQueue and KeyValueStore are always separate things, there are no queues that benefit from having IndexedFifoQueue semantics [16:07:34] hrm i think i agree with that if i understand correctly [16:08:00] we aren't actually doing fifo right? and i don't know that strict fifo really gets us much [16:08:14] ordering by id would be sufficient [16:08:21] One thing that's bugging me is how to deal with multiple keys, though. That might only be necessary when we're talking about expiration, so perhaps the timestamp column is dealt with transparently? [16:08:46] cwd: We want fifo behavior, but with the ability to crash I think [16:09:05] so an uncommitted pop() will not be consumed [16:09:13] right [16:09:18] and then we can go back and select it later [16:09:42] the private data in FifoQueue should support Kafkaesque access [16:10:00] where each consumer group has its own read offset [16:10:42] you just blew my mind [16:10:48] eh? [16:10:59] i just don't understand what you said [16:11:02] oh [16:11:26] kafkaesque access? [16:11:58] um, so I'm thinking that you get a fifoqueue like, DonationQueue::wantFifoQueue("refund", "refund_consumer_grupo") [16:12:18] then, the backend will look up your grupo in a table of stored offsets [16:12:34] if you've never been seen before, you default to reading from the current tail [16:12:46] otherwise, your offset is loaded and that's the ID where pop() begins for you [16:13:15] so like people in line at a conveyor belt? [16:13:43] basically :( [16:13:52] hehe, just trying to visualize it [16:14:05] I only condone that metaphor if they're stealing parts to make a cost < dime car [16:14:20] so we are sold on the idea that there should be parallelized workers? [16:14:24] no [16:14:37] but I'm becoming attached to the persistence [16:15:02] i'm confused, is that what you're describing? [16:15:16] and there's low conceptual overhead to the offset idea, cos it seems to be needed anyway if we're emulating a FIFO in SQL [16:15:58] It is what I'm describing, but we can start with single consumers and I don't think it's wasted functionality [16:16:35] oh i gotcha. so practically speaking would that be like... where primary_key = newest - offset ? [16:16:56] mm [16:17:19] I was imagining, offset would be the primary key [16:19:52] i was actually just installing this postgres thing [16:20:07] just for giggles [16:21:23] lemme... Jeff_Green hi! What do you think about using a postgres or mysql cluster as the store for the "queue" service? [16:22:18] If it's not insecure and a waste of resources, I would be all for it :) [16:24:11] *not mysql [16:24:16] :| [16:24:18] why not? [16:24:37] well it doesn't support listen/notify which would be nice features [16:24:46] and it is just generally a much worse piece of software [16:24:50] hehehe [16:25:33] also mysql.com uses Open Sans which won't display properly in my browser because Fonts [16:25:36] agreed, but it's the same garbage heap we throw all our other data into, which is significant for maintenance [16:25:57] Try rebooting into Linwoes :p [16:26:15] that's true, i was hoping we could sell this as conceptually different enough to be its own service [16:26:41] It needs to be its own service for security reasons, at least [16:27:12] It's also likely that we'll get a lot more HA goodness from postgres [16:28:10] definitely [16:28:27] Still, I thought it would be polite to offer to make a concession to harsh reality, and reuse existing puppetry, etc [16:28:52] certainly [16:30:12] So, I'm interested in stuff like how we create these queue objects [16:30:33] right out of the gate, look how much more sane this is: [16:30:36] postgres=# CREATE USER mypguser WITH PASSWORD 'mypguserpass'; [16:31:11] awight: i'd imagine largely the same as we do now? [16:31:20] at least at first [16:31:22] I have no doubts about pg being like 15 years up on mysql [16:31:43] cwd: I fell out of like with the single factory, is the thing... [16:32:39] Was now imagining, DonationQueue::new($queue_name, ?$consumer_group) for the FifoQueue, but something else for getting a KV store [16:33:21] what goes in the KV store? [16:34:02] that's also bothering me--it's starting to look like a regular database. [16:34:26] yeah. is that bad? [16:34:27] (according to https://www.mediawiki.org/wiki/Fundraising_tech/Message_queues ) [16:34:35] I think only pending [16:34:36] yeah.... [16:35:09] could totally just use payments_init for that [16:35:57] ejegg: btw harebrained dump at https://www.mediawiki.org/wiki/File:Fundraising_queues_class_diagram.svg [16:36:02] ejegg: tell me more ;) [16:37:00] oh, that just occurred to me now [16:37:12] same sort of data, we want to send it around the same time [16:37:43] pending is a bit different cos it's a ton of PII that we often want to destroy in a short timeframe [16:37:53] ah yeah [16:38:25] also, we want to pull pending things by ID [16:38:29] well, we do have to keep it till the payment resolves via audit, which can be a while for some of these methods [16:38:37] awight: postgres--if we're seriously considering databases for the queue I would first want to rule out mysql [16:38:40] maybe it should be a Kafkaesque stream which is consumed into MySQL [16:38:59] Jeff_Green: :D that makes cwd happy [16:39:03] :) [16:39:04] either that or I'd want to go postgres everwhar [16:39:14] sure, that would definitely be fine, I think that's what we were leaning towards last we talked [16:39:21] that would be awesome Jeff_Green [16:39:47] ejegg: That does bring back the specter of antimessages [16:39:57] cos DI wants to "delete" by transaction ID [16:39:59] cwd: I'm confused, which would be awesome? slaying the queue concept? [16:40:08] hehe [16:40:29] awight not so terrible then... [16:40:33] I don't entirely understand why we're using a queue instead of a db anyway, is it just to keep load off the db? [16:40:34] Jeff_Green: I think you said "postres everwhar" and cwd's sky lit with golden halos [16:40:40] yeah that [16:40:59] Jeff_Green: not even load, but to decouple the frontend from sensitive data [16:41:09] awight or whatever inserts the real donation into civi always deletes from pending db [16:41:21] Jeff_Green: there's no reason for it to be a strictly queueing data store, though [16:41:41] Jeff_Green: We're already building the "queue" layer in a way that it can emulate the behavior we want using any type of backend [16:41:48] awight: ok [16:42:10] so the goal is that nothing other than civicrm talks directly to the civi database? [16:42:14] at this point, I just care about * HA * holds data [16:42:26] Jeff_Green: yes [16:43:06] And to state the other practical concern, that the frontend has minimal runtime dependencies on other components [16:44:11] ejegg: ah good point [16:44:52] or we let them expire naturally [16:48:33] cwd: I'm ready to remove all of the K/V stuff from PHP-Queue... lmk if you see any reason not to. [16:49:06] awight: and just treat everything like db rows? [16:49:40] cwd: DonationInterface will only ever push() [16:50:01] Then, consumers will splat completed and pending records into some kind of DB [16:51:05] gotcha. some stuff will need to be purged regularly right? [16:51:07] p2 [16:51:08] Our DMZ sort of jobs (listener, audit, pending processing) will have access to that DB, and will be able to push() things to civi queues [16:51:14] PII [16:51:23] yeah, purging seems a bit twitchy [16:51:26] but doable [16:52:12] sounds like a job for purgebot [16:52:27] Probably, some data gets archived where id < min(offset), and other stuff is just deleted [16:56:20] Seems like this is clear enough that I can fiddle with tasks some more... [16:58:06] Fundraising Sprint Freshmaking, Fundraising Sprint Hermit Crab Husbandry, Fundraising-Backlog, fundraising-tech-ops, and 2 others: Spike: Investigate suitability of Kafka instead of Redis - https://phabricator.wikimedia.org/T130304#2224218 (awight) News flash: MySQL eliminated as a candidate, by... [16:58:48] awight: if you are sold on this idea then heck yes [16:59:39] postgres? I like that idea, but think that the choice of store shouldn't matter for what we're doing [17:00:24] oops-- [17:05:57] awight|meeting, cwd, XenoRyet|afk, AndyRussG : anything for Scrum of Scrums? [17:06:32] ejegg: thx, nothing here :) [17:08:10] ejegg: Nothing from me either. [17:09:24] ok, cool [17:10:27] good here! [17:10:30] thx [17:15:09] hola awight [17:15:14] do you have a minute today to talk sql? :) [17:15:18] cwd: hey [17:15:21] sure! [17:15:30] oops ^ ccogdill :) [17:15:35] k! should I just grab a time on your cal? [17:15:46] Now is good, if you wish [17:15:50] awight: sup [17:15:57] k! [17:16:04] we're all talking sql today! [17:16:06] cwd: erroneously summoned, my bad! [17:16:08] woo! [17:16:14] oh heh [17:16:46] so awight not sure if this is easier to talk out on a call or here… Jessica wanted me to run a sanity check on dash data. not sure if that makes sense or not [17:16:58] but she wanted me to find the top day, top hour, etc [17:17:01] totally makes sense [17:17:02] and I don’t know how to do that [17:17:17] https://collab.wikimedia.org/wiki/Fundraising/Engineering/Fun_SQL_Queries has those exact queries, IIRC [17:17:31] yup [17:17:34] ughh should have checked there [17:17:44] har no worries! [17:18:27] cool I will run through these and let you know if I get confused [17:18:29] thanks :p [17:36:59] I can almost see the bottom of my inbox... a triple digit unread count for the first time this year :/ [17:38:53] 999 to go! [17:40:11] gargh [17:49:32] Fundraising-Backlog, fundraising-tech-ops, FR-ActiveMQ: [Epic] Provision high-availability Kafka cluster for Fundraising - https://phabricator.wikimedia.org/T130283#2224408 (Ottomata) Have you talked to Services folks about this? This sounds very familiar to the job queuing stuff they are doing for... [17:50:19] Fundraising-Backlog, MediaWiki-extensions-DonationInterface, FR-Astropay: AstroPay should be the preferred payment method for supported countries - https://phabricator.wikimedia.org/T133181#2224409 (awight) [17:50:34] Fundraising Sprint Hermit Crab Husbandry, Fundraising-Backlog, MediaWiki-extensions-DonationInterface, Unplanned-Sprint-Work, FR-Astropay: AstroPay should be the preferred payment method for supported countries - https://phabricator.wikimedia.org/T133181#2224421 (awight) p:Triage>Unbre... [17:50:41] the-wub: ^ fyi [17:51:07] thanks awight :) [17:53:38] Fundraising-Backlog, fundraising-tech-ops, FR-ActiveMQ: [Epic] Provision high-availability Kafka cluster for Fundraising - https://phabricator.wikimedia.org/T130283#2224430 (Ottomata) Also, have you seen this library? https://github.com/arnaud-lb/php-rdkafka It looks fairly up to date: #define PHP_... [17:54:44] Fundraising Sprint Hermit Crab Husbandry, Fundraising-Backlog, MediaWiki-extensions-DonationInterface, Unplanned-Sprint-Work, FR-Astropay: AstroPay should be the preferred payment method for supported countries - https://phabricator.wikimedia.org/T133181#2224431 (awight) Here's an example of... [18:00:58] Fundraising-Backlog, fundraising-tech-ops, FR-ActiveMQ: [Epic] Provision high-availability Kafka cluster for Fundraising - https://phabricator.wikimedia.org/T130283#2224440 (awight) @Ottomata Yes, that one was my top choice, see T131268 for some explanation. Thanks to the tip about Services, T88459... [18:02:10] Fundraising Sprint Hermit Crab Husbandry, Fundraising-Backlog, MediaWiki-extensions-DonationInterface, Unplanned-Sprint-Work, FR-Astropay: AstroPay should be the preferred payment method for supported countries - https://phabricator.wikimedia.org/T133181#2224409 (Pcoombe) FWIW I refreshed tha... [18:06:26] unread in the double digits! [18:09:32] Fundraising Sprint Hermit Crab Husbandry, Fundraising-Backlog, MediaWiki-extensions-DonationInterface, Unplanned-Sprint-Work, FR-Astropay: AstroPay should be the preferred payment method for supported countries - https://phabricator.wikimedia.org/T133181#2224493 (awight) Uh, oh... selection i... [18:26:21] Fundraising Sprint Hermit Crab Husbandry, Fundraising-Backlog, MediaWiki-extensions-DonationInterface, Unplanned-Sprint-Work, FR-Astropay: AstroPay should be the preferred payment method for supported countries - https://phabricator.wikimedia.org/T133181#2224616 (Pcoombe) We're now appending... [18:28:19] Fundraising Sprint Hermit Crab Husbandry, Fundraising-Backlog, MediaWiki-extensions-DonationInterface, Unplanned-Sprint-Work, FR-Astropay: AstroPay should be the preferred payment method for supported countries - https://phabricator.wikimedia.org/T133181#2224617 (awight) p:Unbreak!>Hig... [18:31:15] (PS1) Awight: Use selection weights deterministically [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/284503 (https://phabricator.wikimedia.org/T133181) [18:38:17] Fundraising-Backlog, FR-ActiveMQ: Remove KeyValueStore from PHP-Queue - https://phabricator.wikimedia.org/T133190#2224646 (awight) [18:38:35] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, MediaWiki-extensions-DonationInterface, Epic, and 3 others: [Epic] Clean up "pending" queue usages - https://phabricator.wikimedia.org/T130897#2224662 (awight) [18:39:43] Fundraising Sprint Hermit Crab Husbandry, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, MediaWiki-extensions-DonationInterface, and 4 others: [Epic] Clean up "pending" queue usages - https://phabricator.wikimedia.org/T130897#2149972 (awight) [18:40:00] cwd|afk: fyi, something concrete to add to the current sprint... ^ [18:43:16] Excellent [18:45:43] Fundraising Sprint Hermit Crab Husbandry, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, MediaWiki-extensions-DonationInterface, and 4 others: [Epic] Clean up "pending" queue usages - https://phabricator.wikimedia.org/T130897#2224731 (awight) [18:47:03] Fundraising Sprint Hermit Crab Husbandry, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, MediaWiki-extensions-DonationInterface, and 4 others: All pending producers should write to a single pending queue - https://phabricator.wikimedia.org/T133195#2224734 (awight) [18:48:45] Fundraising Sprint Hermit Crab Husbandry, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, MediaWiki-extensions-DonationInterface, FR-ActiveMQ: Write pending queue consumer and schema - https://phabricator.wikimedia.org/T133197#2224770 (awight) [18:49:01] Fundraising Sprint Hermit Crab Husbandry, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, MediaWiki-extensions-DonationInterface, and 3 others: All pending producers should write to a single pending queue - https://phabricator.wikimedia.org/T133195#2224734 (awight) [18:52:17] Fundraising Sprint Hermit Crab Husbandry, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, MediaWiki-extensions-DonationInterface, and 3 others: All pending producers should write to a single pending queue - https://phabricator.wikimedia.org/T133195#2224806 (awight) [18:52:18] (PS2) Ejegg: Turn on client-side amount validation for new forms [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/284367 (https://phabricator.wikimedia.org/T132959) [18:53:14] Fundraising Sprint Hermit Crab Husbandry, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, MediaWiki-extensions-DonationInterface, FR-ActiveMQ: Write pending queue consumer and schema - https://phabricator.wikimedia.org/T133197#2224814 (awight) [18:53:16] Fundraising Sprint Hermit Crab Husbandry, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, MediaWiki-extensions-DonationInterface, and 3 others: All pending producers should write to a single pending queue - https://phabricator.wikimedia.org/T133195#2224734 (awight) [18:53:46] Fundraising Sprint Hermit Crab Husbandry, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, MediaWiki-extensions-DonationInterface, and 4 others: [Epic] Clean up "pending" queue usages - https://phabricator.wikimedia.org/T130897#2224815 (awight) [18:53:48] Fundraising Sprint Hermit Crab Husbandry, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, MediaWiki-extensions-DonationInterface, FR-ActiveMQ: Write pending queue consumer and schema - https://phabricator.wikimedia.org/T133197#2224770 (awight) [18:56:03] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, MediaWiki-extensions-DonationInterface, FR-ActiveMQ, FR-Smashpig: Formalize schema for all message types - https://phabricator.wikimedia.org/T131272#2224840 (awight) [18:56:36] Fundraising Sprint Hermit Crab Husbandry, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, MediaWiki-extensions-DonationInterface, and 2 others: Formalize schema for all message types - https://phabricator.wikimedia.org/T131272#2161844 (awight) [18:58:55] Anyone remember why we don't have a sprint thing today? [19:02:49] nope, I was wondering the same! [19:08:53] We could IRC that [19:09:14] works for me! [19:09:18] I'm getting confident about the first step for queue overhauling... [19:09:35] https://phabricator.wikimedia.org/T130897 [19:09:58] The three subtasks can be done in parallel, if anyone cares to jump in! [19:10:40] I removed some Kafka tasks from the sprint, and replenished them with these. [19:10:49] I've got fixes for the minimum amount error: https://gerrit.wikimedia.org/r/284366 , https://gerrit.wikimedia.org/r/284367 [19:12:08] (PS1) Ejegg: WIP Initial reorganization of js for new forms [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/284508 (https://phabricator.wikimedia.org/T86248) [19:12:40] And a start at reorganizing all the mustache form javascript ^^ [19:13:37] (CR) jenkins-bot: [V: -1] WIP Initial reorganization of js for new forms [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/284508 (https://phabricator.wikimedia.org/T86248) (owner: Ejegg) [19:13:59] Fundraising Sprint Hermit Crab Husbandry, Fundraising Tech Backlog, Fundraising-Backlog, MediaWiki-extensions-DonationInterface, Easy: Don't make donors guess minimum donation amount - https://phabricator.wikimedia.org/T105618#2224919 (Ejegg) a:Ejegg [19:14:45] (PS3) Ejegg: Turn on client-side amount validation for new forms [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/284367 (https://phabricator.wikimedia.org/T105618) [19:19:25] (PS2) Ejegg: WIP Initial reorganization of js for new forms [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/284508 (https://phabricator.wikimedia.org/T86248) [19:20:08] (PS1) Ejegg: Fix blank email error message [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/284509 [19:21:00] (CR) jenkins-bot: [V: -1] WIP Initial reorganization of js for new forms [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/284508 (https://phabricator.wikimedia.org/T86248) (owner: Ejegg) [19:27:42] (CR) Awight: [C: 2] "I've been denied! This works and is elegant." [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/284366 (https://phabricator.wikimedia.org/T132959) (owner: Ejegg) [19:28:25] (PS3) Ejegg: WIP Initial reorganization of js for new forms [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/284508 (https://phabricator.wikimedia.org/T86248) [19:29:10] (Merged) jenkins-bot: Account for gateway-specific min/max client-side [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/284366 (https://phabricator.wikimedia.org/T132959) (owner: Ejegg) [19:29:49] (CR) jenkins-bot: [V: -1] WIP Initial reorganization of js for new forms [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/284508 (https://phabricator.wikimedia.org/T86248) (owner: Ejegg) [19:31:20] oh huh, we really do enforce spaces inside square brackets for js... thought that was grunt acting funny locally [19:31:32] (CR) Awight: [C: 2] Turn on client-side amount validation for new forms [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/284367 (https://phabricator.wikimedia.org/T105618) (owner: Ejegg) [19:32:06] watertight validation js, thanks! [19:32:34] That editable amount is growing on me--the arrow keys even work! [19:32:57] (Merged) jenkins-bot: Turn on client-side amount validation for new forms [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/284367 (https://phabricator.wikimedia.org/T105618) (owner: Ejegg) [19:33:12] thanks for the CR awight! [19:33:21] input type=number! [19:33:51] i think we could even give it bounds corresponding to priceFloor and priceCeiling [19:36:48] Attach a big slider, w actions and a preview of what your donation is buying us... [19:38:22] that WIP is thrilling :) [19:38:27] (PS4) Ejegg: Initial reorganization of js for new forms [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/284508 (https://phabricator.wikimedia.org/T86248) [19:39:04] watching those window.* lines just melt away [19:39:50] you're running over the home plate and another lap with that one [19:43:17] ehhh, it's a start anyway [19:47:13] I get a session problem with http://payments.dev/index.php?title=Special:AdyenGateway&appeal=JimmyQuote&payment_method=cc&recurring=&uselang=en&language=en¤cy_code=USD&country=US&amount=.1 [19:47:22] awight: what if the new pending queue _was_ the new implementation [19:47:24] The warning text is never disabled [19:47:43] cwd: That's perfect [19:48:00] the first proof, just move one thing at a time to it [19:48:51] the consumer processing job is another extension point we would have to pioneer as part of phase 1 [19:49:08] indeed [19:49:17] For pending, it writes to a db. [19:49:29] but isn't it basically a php script that loads some classes and calls a function? [19:49:35] hrm, event vs batch [19:49:41] yep [19:49:48] awight: ooh, right, because that one does an ajax submission [19:49:55] ejegg: I think so [19:50:15] ajax call...from a script? [19:50:17] donno if you want to fix that in a followup [19:50:28] oh, you're talking about different things :P [19:50:36] cwd: ejegg is on about this masterpiece ;) https://gerrit.wikimedia.org/r/#/c/284508 [19:50:57] oh awesome [19:51:05] i have personally duplicated a lot of that js [19:51:21] ok, that's a good excuse to bring in T112323 [19:51:21] T112323: Mustache forms should provide server-side error map to client-side script - https://phabricator.wikimedia.org/T112323 [19:51:33] wat. [19:51:33] well hello stashbot! [19:51:39] neat [19:52:26] cwd: Want to draw one of these? https://phabricator.wikimedia.org/T130897 [19:53:00] one of the blockers? [19:53:13] yah--lemme try kicking the 'bot, T133197 T133195 T131275 [19:53:13] T131275: Move orphan rectifier out of payments - https://phabricator.wikimedia.org/T131275 [19:53:13] T133195: All pending producers should write to a single pending queue - https://phabricator.wikimedia.org/T133195 [19:53:13] T133197: Write pending queue consumer and schema - https://phabricator.wikimedia.org/T133197 [19:53:18] <3 [19:53:49] Now if only I could copy text out of Phabricator without getting ten ajax effects rather than a selection [19:53:53] (PS5) Ejegg: Initial reorganization of js for new forms [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/284508 (https://phabricator.wikimedia.org/T86248) [19:54:21] awight: love to. want to talk after standup? [19:55:07] stashbot: You reach down and flip the tortoise over on its back. [19:55:22] whaddyou mean, i'm NOT helping [19:55:44] hehe [19:57:24] cwd: we were sort of doing IRC standup earlier btw [19:57:47] AndyRussG|a-whey: XenoRyet: ^ [19:57:52] oh sorry [19:58:04] jumping the gun on the non-meeting [19:58:12] AndyRussG: oh, hi! [19:58:14] uhm, i was messing with audit stuff but then got sweap away into queue world [19:58:22] :) [19:58:22] cwd: awight: hi! Yeah I saw there was no meeting on the calendar [19:58:43] but that reminds me ejegg kindly merged a couple things that should let the worldpray jobs finish [19:59:00] so i probably need to get Jeff_Green to move like everything in that directory again [19:59:31] or look the other way while i use the jenkins web interface to chmod g+w the directory [19:59:31] That's great. Such a sketchy workaround [19:59:51] slick :D [20:00:09] all things should be umask 002 [20:00:26] I'm working on the cookie plan. Wrote an e-mail/Phab message, read over some of our current cookieful code, and am about to send 1 or maybe 2 specific proposals, at least one of which I think might be accepted pronto [20:01:18] heh [20:01:33] because they look yummie! [20:01:40] sorry, heh was not to the cookie plan! [20:01:56] Ah, IRC standup today eh? [20:01:57] but to the workaround [20:02:12] XenoRyet: yah, we seem to not have a calendar entry [20:02:22] Noticed that. IRC is cool with me. [20:02:23] yeah weird [20:02:53] AndyRussG: awesome, I'll take a look at your cookie proposals [20:02:59] I'm just doing those Adyen forms. If there's some DI stuff that needs quick review I could probably switch over though. Saw some things that looked urgent flying around this morning. [20:03:16] ejegg: cool! yeah specific thing coming up in a few... thx!!! [20:03:34] grouting the tile tonight and will actually shower at home on friday morning [20:03:42] nice [20:04:48] did 3 hrs of caulking last night [20:04:49] Looks like the calendar entry is super fragile, it was every other week and 12 weeks, so it expired. I've renewed our membership for 2 weeks from now :) [20:06:49] http://i.imgur.com/tphtKec.jpg [20:07:15] Oh, that's damn pretty! [20:07:39] nice, looks great! [20:07:44] turned out ok for a 1st time tiler [20:10:04] I bet I got a job for you when you park in California :) [20:10:19] Actually, I have a pile of broken glass and plates, to make a fresco. [20:10:24] Which I do not know how to do yet [20:10:48] my mom used to do a lot of stained glass [20:10:54] oh, wow! [20:10:56] with a gigantic soldering iron [20:11:02] and gigantic solder [20:11:04] I hope you have the artifacts [20:11:25] i think they were mostly left in houses [20:11:35] poetic [20:11:51] they renovated houses my whole childhood [20:12:10] It's much more relaxing than renting :) [20:12:25] so they are good people to call when you are for instance redoing your bathroom in a panic [20:13:04] I'm sure they love to give advice 8) [20:13:22] you got that right [20:13:39] hey - just reading the logs you did irc standup? I saw last night it wasn't in the calendar so assumed there wasn't one [20:13:46] +1 [20:14:16] cos there was no notice and crazy [20:14:33] sorry to add today's entry, that was inadvertent [20:15:33] ah right. my standup is just that I started looking into dedupe & hit a bad query I had to look into [20:16:16] ejegg: there are 11 files from 4/1 in the worldpay completed audit dir that are owned by you...does that sound familiar at all? [20:16:29] eileen: that sounds fun! [20:16:40] (lol) [20:16:44] cwd: April fools! [20:16:54] hmm, no, I totally forget what I was doing then [20:17:27] hehe [20:17:29] need me to move them or chmod them or something? [20:17:55] well i found a missing txn in one of them and was just thinking of reprocessing [20:18:12] awight: the "I didn't know or was awful bug rears it's head" [20:18:18] but tbh we might want to just reprocess everything since feb or something [20:18:25] with the new stuff in place [20:18:44] should be kosher [20:18:49] https://issues.civicrm.org/jira/browse/CRM-18442 [20:18:58] cwd: btw the "One-time scripts" Jenkins job is ready-made for sneakily running sh and so on, in case u haven't edited that yet [20:19:02] ok, I'll try to get em back how they should be [20:19:54] thanks! [20:20:00] eileen: nice blooper! [20:20:03] awight: i did come across that once [20:20:07] :-) [20:20:38] cwd worldpay completed? [20:20:58] not seeing anything owned by ejegg there [20:21:22] nor worldpay incoming [20:23:09] eileen: Could you avoid the union as well, by removing the contact_id inequality? [20:23:31] ejegg: yep [20:24:00] awight: the point of that is to get each pair once [20:24:23] hmmm one sec [20:24:24] ie. 4,5: 4,7: 6,5 [20:24:41] not 4,5 : 4, 7: 5,4:, 5,6 [20:24:46] ejegg: oh i'm sorry, GC not WP [20:25:00] k [20:27:31] i like things that differentiate between ' and " [20:27:47] that's a good venue for encoding meaning that just ends up a muddled mess in most languages [20:28:16] eileen: Hum, that's tricky. Seems like the only duplicated pairs would be if c2.contact_id was also in the set of c1.ids that we're searching for. [20:28:27] cwd ok, just made em group writable [20:29:02] eileen: oooh, now I see, thanks. we're getting exactly those three pairs [20:29:17] ejegg: thanks! should i use the jenkins interface to move them back to /incoming? [20:29:49] cwd: phooey, I guess so, to avoid claiming them all for yourself [20:30:26] would i even be able to move them back without write perms on /incoming? [20:30:55] hehe maybe they will all be rm'ed [20:34:04] Fundraising Sprint Hermit Crab Husbandry, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, MediaWiki-extensions-DonationInterface, FR-ActiveMQ: Write pending queue consumer and schema - https://phabricator.wikimedia.org/T133197#2224770 (awight) a:awight [20:34:29] awight: I did get it to run but it rejected a whole lot as conflicts, presumably ones with different addresses but I have to dig more to be sure [20:34:49] my thinking is… they shouldn't be merged first time around [20:36:51] That sounds right. Leaving riskier merges for later is a great plan [20:37:32] (CR) Ejegg: "did you really intend to disable the Japan form?" [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/284503 (https://phabricator.wikimedia.org/T133181) (owner: Awight) [20:39:34] Fundraising Tech Backlog, MediaWiki-extensions-DonationInterface: Spike: Choose new template engine for DonationInterface and plan integration - https://phabricator.wikimedia.org/T91673#2225261 (Ejegg) Open>Resolved a:Ejegg Mustache! [20:40:38] (CR) Awight: Use selection weights deterministically (1 comment) [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/284503 (https://phabricator.wikimedia.org/T133181) (owner: Awight) [20:49:56] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, MediaWiki-extensions-DonationInterface, FR-ActiveMQ, FR-Smashpig: Consolidate queue abstractions - https://phabricator.wikimedia.org/T131271#2225324 (awight) [20:55:25] awight: if we used sql for the queues, would each one be a different table? [20:55:48] I was thinking yes [20:56:13] that would let us do some ACL if we cared, and tricky disk or maintenance things [20:56:38] cwd: What do you think about defining a schema per queue? [20:56:45] one thing i did with my implementation was make the payload json (native type in postgres :) so that schema changes wouldn't blow [20:57:00] you can even query deep into json fields [20:57:36] Do you still have indexes? [20:57:47] like, timestamp, transaction ID... [20:57:51] yeah you can index the json too [20:58:03] oh, well those are top level fields [20:58:15] whoa [20:58:18] the json i figured would just describe a function call with parameters or something [20:58:24] there's a field called payload that is json [20:59:22] _but_ i also think it's worth noting that select even w/o indexes are not that painful in a fifo situation [20:59:51] should we have a "type" field, or are all messages in a queue the same type? [21:00:23] i'm ambivalent, one giant table or a bunch of identical tables [21:00:28] sorry--I'm way off base [21:00:52] for some reason, I've been talking about the db schema for consumed pending messages [21:01:09] yeah, for the FIFO emulation on a database, I like the idea of a table per queue [21:01:27] but there's definitely a generic schema like you're suggesting [21:01:45] awight: https://github.com/caseydentinger/glerk/blob/master/example.sql [21:01:50] only one index, the sequence of how they came in [21:02:08] we never do any queries other than pop() [21:02:31] but other jobs will come along and do other stuff right? [21:02:36] with messages that get left behind? [21:02:37] If you do geek out on that emulation layer, please make a task for it btw... [21:02:40] (PS1) Ejegg: Remove errors when things look good [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/284532 (https://phabricator.wikimedia.org/T112323) [21:02:40] I hadn't yet [21:02:56] and... maybe start with PHP-Queue/../PDO.php [21:03:06] well i'd love to determine if it's worth it [21:03:34] cwd: I'm trying to stick to plan K, where there is a wall of FIFO behind the frontend [21:03:49] in this reality there needs to be _something_ running as a service watching the queue and shelling out php. it could be php, but i don't see a real good reason [21:03:54] everything behind that big fiery queue is a simple fifo queue consumer [21:04:11] we never write back or selectively delete from the fifos [21:04:36] once we've popped, however, we do stuff like jam rows into a pending database, or process into the CRM [21:04:53] yeah, so this go thing just marks it complete on exit 0 and failed on exit 1 [21:05:10] cwd: +1 we should be free to write the consumer in whatever langauge [21:05:32] awight: but i don't even mean the worker, there needs to be something factorying out the workers [21:05:45] however, handling transactionality seems to be a sticking point if you want to glue a batch e.g. python consumer to a PHP row or batch processor [21:05:56] cwd: write it up! [21:05:58] polling the queue, or better yet using listen and notify [21:06:04] that's what this golang thing i made is [21:06:17] i have it set up on my laptop now just shelling out no-op php scripts [21:06:48] +1 that our FIFO interface could have a sugary flavor of efficient blocking and batching read [21:07:08] So what granularity would you prefer to run PHP at? [21:07:16] per row? Or per batch? [21:07:31] that's a good question [21:07:41] ah I see your response above-- yeah a non-zero exit code means the whole batch need reprocessing [21:08:04] making jobs manditorily idempotent is sort of annoying [21:08:06] per row seems a lot simpler to me, unless there is additional schema [21:08:10] *dator [21:08:35] starting our PHP is a huge investment... [21:08:44] yeah [21:09:01] yeah that's a good point [21:09:21] but I would *love* to not have a dependency from PHP to the FIFO backend or even wrapper library [21:09:36] so we could feed the machine ticker tape or whatever we cobble together. [21:09:55] yeah totally [21:10:07] Maybe--that is one mode that we support [21:10:12] i wouldn't want the simple fifo interface to have to have the brains for this [21:10:24] but for a production thing, we use our native PHP shim? [21:10:42] gah [21:10:56] Seems like there should be a simple solution--mutex on processing each transaction or something. [21:11:23] the nature of php is rough [21:11:33] fire up/tear down everything every time [21:12:22] I wonder if there's something we can do with straight up pipes [21:13:07] it might be easiest to just rewrite this daemon in php [21:13:10] as much as it pains me [21:13:19] * awight wilts [21:13:19] although we totally lose concurrency [21:14:02] go has goroutines which are internally managed threads [21:14:43] lots of the benefits of fork with a lot less headache [21:15:51] I'm secretly happy to never expect to wrap my head around a threading implementation for PHP [21:15:56] imagine that API... [21:16:17] pretty much like...lxc per php [21:16:22] (CR) Ejegg: "Let's not touch the JP form - looks like it really is being chosen consistently for JP/cc" (1 comment) [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/284503 (https://phabricator.wikimedia.org/T133181) (owner: Awight) [21:18:32] awight: whatever we do here is going to get dumbed down to php's level at some point anyway so maybe writing the listener in php is fine [21:18:47] It's a small piece, regardless. [21:18:53] maybe you can pass it an autoloader so it has everything it will need [21:19:07] so it can sit with all the classes loaded and process messages [21:19:25] one of those per queue [21:26:39] 4/20 in boulder ain't what it used to be a tell you what [21:28:05] used to be like the super bowl was in town but i guess no one cares now that it's legal [21:36:02] Oh hey, it's a special occasion! [21:36:51] (PS1) Ejegg: Align amount and currency inputs [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/284596 (https://phabricator.wikimedia.org/T113306) [21:37:05] awight: grrr well now i'm not sure what i think [21:37:16] Fundraising Sprint Hermit Crab Husbandry, Fundraising-Backlog, Unplanned-Sprint-Work, Patch-For-Review: Style fields more cleanly for when donor enters form without currency or amount - https://phabricator.wikimedia.org/T113306#2225510 (Ejegg) [21:37:43] if we're going to have to basically write a queue in php maybe a real queue is better [21:38:01] https://www.rabbitmq.com/tutorials/tutorial-one-php.html [21:41:05] That part's covered by PHP-Queue, we just point and click at it [21:42:24] ah yeah you said it supports mysql? [21:43:08] Fundraising Sprint Ghostbusting , Fundraising Sprint Hermit Crab Husbandry, Fundraising-Backlog, MediaWiki-extensions-CentralNotice: CentralNotice: Make a plan for moving stuff out of cookies - https://phabricator.wikimedia.org/T131319#2225522 (AndyRussG) Some specific proposals, regarding the po... [21:43:26] ejegg (and anyone else interested, of course) ^ [21:43:26] (PS1) Awight: [WIP] Integrate with PHP-Queue [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/284597 [21:43:44] cwd: ^ I think that's all the glue we need for now... [21:44:07] (PS2) Awight: [WIP] Integrate with PHP-Queue [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/284597 (https://phabricator.wikimedia.org/T131271) [21:44:11] thanks AndyRussG [21:44:18] cwd: PHP-Queue supports PDO [21:44:20] Au contraire, thanke U! [21:45:10] awight: will this poll the db? [21:45:25] yes, pop() will [21:46:08] awight: do you imagine just throwing the mysql implementation at postgres? [21:46:17] ejegg: awight if you want to comment … https://issues.civicrm.org/jira/browse/CRM-18443 [21:46:31] It's written using PDO, so it's not technically a mysql impl... [21:46:59] actually perhaps I should make sure I always email ft-tech when I log a JIRA that is wmf-related? [21:47:05] ah good point [21:47:08] thanks eileen , I'll take a look [21:48:07] awight: will it leave the socket open and query the table at an interval? [21:48:36] eileen: Great to surface this in the API! [21:48:54] cwd: no, it'll return null or throw an EmptyQueue exception or some such thing [21:49:23] the polling can happen at a higher level, or we can eventually add a blocking read option to PHP-Queue's pop [21:49:56] ok cool [21:50:06] select...for update is easy [21:50:25] i mean "select...for update" is easy [21:52:06] interesting--I meant the other blocking, where the pop() doesn't return until data appears, or timeout [21:53:04] oh i gotcha, yeah [21:53:17] in the mean time as long as it's sufficiently rate limited i'd guess it's fine [21:53:21] Fundraising Sprint Ghostbusting , Fundraising Sprint Hermit Crab Husbandry, Fundraising-Backlog, MediaWiki-extensions-CentralNotice: CentralNotice: Make a plan for moving stuff out of cookies - https://phabricator.wikimedia.org/T131319#2225569 (Ejegg) Proposal B is really tempting for consistency... [21:53:30] relocating... [21:54:04] but i could see crushing some servers with unrestricted polling [21:54:30] cwd: For now, I'm just dropping into the existing job, so it will be called once every c. 2 minutes. If there are messages, we pop until null. Otherwise, exit [21:55:00] cool yeah, that sounds great [21:55:45] ejegg|afk: thx! [21:55:51] Feel free to design the polling sugar that we'll write for the next generation [21:56:21] sure, if it's just PDO we could still do listen/notify [21:56:29] I'm not familiar with the best practice there. It does seem like we want both batching and i/o blocking, though [21:56:51] cwd: it still needs some designing beyond that, I think [21:57:12] i just imagine that instead of the 2m check [21:57:19] for example, the go app you showed me has a hybrid select/listen thing happening, sort of haphazardly [21:58:07] seems like we should have known characteristics, like it waits up to 30 seconds or 100 messages, whatever comes first, then restarts immediately after finishing processing. [21:58:34] do you mean select(2) ? [21:58:55] pretty much, but plus a batching thing. [22:00:40] yeah it's just a go construct, not the actual system call [22:00:46] but analogous [22:01:26] awight: do you mean it waits until 100 messages are ready and then processes them as a batch? [22:01:40] that was on my mind [22:03:49] is that to avoid loading the app up multiple times? [22:04:15] yeah, and also to make 1% of the queries [22:04:56] Although maybe LISTEN already eliminates that overhead by waiting for a push from the server? [22:05:27] it eliminates the polling yeah but doesn't help with the batching [22:06:07] the batching is interesting, it would be nice if it wasn't too tightly coupled between the components [22:06:23] yes, exactly! [22:06:26] but, transactions... [22:06:40] want to lick that cookie? [22:06:42] yeah, that's why it would be nice to be able to do one job at a time [22:06:45] yeah sure [22:06:48] hehehe [22:07:07] if the thing handing out the jobs was also the thing running the jobs it would be ok to share that concern [22:07:19] if it could load up the app and just sit there with it loaded [22:07:38] long running php sucks but it seems inevitable [22:08:46] Unsafe at any speed... [22:08:56] Better to change those tires before they're even bald [22:09:18] if the scheduler waits for 100 jobs then says ok go process jobs now the state of the database is a hidden input to the processor function [22:09:49] it would be less stateful if it passed the actual jobs somehow [22:09:53] through way to put it! [22:09:59] *thorough [22:13:35] well i'll definitely cat vacuum this problem to death in the near future but i really need to get the last of these audit records accounted for [22:13:38] i have been kicking the can [22:15:33] I can always help with procrastination [22:16:19] i'll be damned, i _can_ write GC audit dir [22:16:50] did this change recently? i swear i have tried several times [22:17:49] phpunit --tarp [22:23:06] (PS2) Awight: Use selection weights deterministically [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/284503 (https://phabricator.wikimedia.org/T133181) [22:23:59] (CR) Awight: "You're right, good reading of those crazy filters! /me adds to "needs documentation"" [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/284503 (https://phabricator.wikimedia.org/T133181) (owner: Awight) [22:29:40] awight: you might have noticed by now I don't trust any core functionality unless it has an api & a unit test... [22:32:49] (PS3) Ejegg: Use selection weights deterministically [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/284503 (https://phabricator.wikimedia.org/T133181) (owner: Awight) [22:35:27] (CR) Ejegg: [C: 2] "agreed, let's push the A/B testing back towards the banners and let 'em use explicit ffnames" [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/284503 (https://phabricator.wikimedia.org/T133181) (owner: Awight) [22:36:50] (Merged) jenkins-bot: Use selection weights deterministically [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/284503 (https://phabricator.wikimedia.org/T133181) (owner: Awight) [22:43:35] i think the GC audit job is a value of hosed that eclipses these missing transactions [22:44:15] timing out and so on [22:45:37] /p\ [22:45:51] There are things we can do... [22:46:10] it seems like it's working harder not smarter [22:46:19] and parsing all the things [22:46:44] u got it. That is one hard-working script [22:46:55] Not like the Silverpop export, though ;) [22:47:24] oh it takes an hour and a half to time out too [22:47:31] * cwd should have looked at that before pressing go [22:58:01] The pain! [23:01:29] Fundraising Sprint Asbestos Removal 2016, Fundraising Sprint Bloodletting 2016, Fundraising Sprint Cat Herding, Fundraising Sprint Dirt Farming, and 6 others: Some Ingenico donations not in Civi - https://phabricator.wikimedia.org/T122730#2225754 (cwdent) I am copying some info from T130129 so we... [23:02:28] cwd: Error logs parsing is on my hit list btw, during this queue overhaul. [23:02:50] Those lines we look for should just be in their own queue -> database table [23:03:00] Fundraising Sprint Hermit Crab Husbandry, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, FR-WMF-Audit: Some Ingenico refunds & cancels not reaching Civi - https://phabricator.wikimedia.org/T130129#2126639 (cwdent) [23:03:02] Fundraising Sprint Asbestos Removal 2016, Fundraising Sprint Bloodletting 2016, Fundraising Sprint Cat Herding, Fundraising Sprint Dirt Farming, and 6 others: Some Ingenico donations not in Civi - https://phabricator.wikimedia.org/T122730#2225761 (cwdent) [23:03:25] awight: yeah that has definitely been on my radar [23:03:33] structure that data on the way in somehow [23:04:02] That's the entirety of the audit problem, anyway... [23:04:16] yeah, scanning filez by time [23:04:23] fanning out in every direction [23:04:34] building an in-memory database... [23:05:10] it's easy to see why it is how it is [23:05:21] but the problem has outgrown that approach [23:11:12] (PS3) Awight: [WIP] Integrate with PHP-Queue [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/284597 (https://phabricator.wikimedia.org/T131271) [23:11:14] (PS1) Awight: Straighten out test namespaces; reusable config setup [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/284612 [23:12:12] (CR) jenkins-bot: [V: -1] [WIP] Integrate with PHP-Queue [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/284597 (https://phabricator.wikimedia.org/T131271) (owner: Awight) [23:12:23] (CR) jenkins-bot: [V: -1] Straighten out test namespaces; reusable config setup [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/284612 (owner: Awight) [23:43:24] (PS4) Awight: [WIP] Integrate with PHP-Queue [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/284597 (https://phabricator.wikimedia.org/T131271) [23:43:26] (PS2) Awight: Straighten out test namespaces; reusable config setup [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/284612 [23:43:28] (PS1) Awight: Validate config paths when loading cached values [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/284614 [23:43:30] (PS1) Awight: Cheat encapsulation to allow us to reset the configuration context [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/284615 [23:44:15] (CR) jenkins-bot: [V: -1] [WIP] Integrate with PHP-Queue [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/284597 (https://phabricator.wikimedia.org/T131271) (owner: Awight) [23:44:25] (CR) jenkins-bot: [V: -1] Straighten out test namespaces; reusable config setup [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/284612 (owner: Awight) [23:44:37] (CR) jenkins-bot: [V: -1] Validate config paths when loading cached values [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/284614 (owner: Awight) [23:44:48] (CR) jenkins-bot: [V: -1] Cheat encapsulation to allow us to reset the configuration context [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/284615 (owner: Awight) [23:58:15] (PS5) Awight: [WIP] Integrate with PHP-Queue [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/284597 (https://phabricator.wikimedia.org/T131271) [23:58:17] (PS2) Awight: Validate config paths when loading cached values [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/284614 [23:58:19] (PS3) Awight: Straighten out test namespaces; reusable config setup [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/284612 [23:58:23] (Abandoned) Awight: Cheat encapsulation to allow us to reset the configuration context [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/284615 (owner: Awight)