[02:07:51] 10Phabricator, 10Project-Admins, 10Triagers: Add Smalyshev to Triagers - https://phabricator.wikimedia.org/T169280#3393643 (10Paladox) [10:36:35] 10Phabricator: Add Smalyshev to Triagers - https://phabricator.wikimedia.org/T169280#3394295 (10Aklapper) 05Open>03Resolved a:03Aklapper @Smalyshev: Done! :) @Paladox: Unrelated to #Project-Admins; see [[ https://phabricator.wikimedia.org/tag/triagers/ | project description ]]. [10:43:15] 10Project-Admins: African Wikimedia Developer Project and Workboard - https://phabricator.wikimedia.org/T168778#3394338 (10Aklapper) 05Open>03Resolved a:03Aklapper Requested public project #Africa-Wikimedia-Developers has been created: https://phabricator.wikimedia.org/project/view/2858/ I've made @D3r1ck... [10:59:33] 10Project-Admins, 10Africa-Wikimedia-Developers: African Wikimedia Developer Project and Workboard - https://phabricator.wikimedia.org/T168778#3394392 (10D3r1ck01) [11:00:36] 10Project-Admins, 10Africa-Wikimedia-Developers: African Wikimedia Developer Project and Workboard - https://phabricator.wikimedia.org/T168778#3376564 (10D3r1ck01) Thanks so much for creating this project @Aklapper. Your message under this ticket is a great source of information and we will hold on to it in ti... [11:09:22] 10Project-Admins: Create a tag for phame posts that are "periodic-update" - https://phabricator.wikimedia.org/T166952#3394463 (10Aklapper) a:03Halfak [16:34:29] 10Phabricator: Phabricator "Duplicate entry" error when moving tasks between workboard columns - https://phabricator.wikimedia.org/T169352#3395507 (10Quiddity) [20:20:53] twentyafterfour: I had to disable a user because of e-mail bounces. That's still the proper course of action, right? [20:21:08] RainbowSprinkles: yeah [20:21:22] it's annoying but I don't know any other way to deal with it [20:22:17] I mean Phab can detect a bounce, ideally there'd be a way to define a threshold at which we stop sending e-mails (a la mailman) [20:22:28] yeah [20:22:36] that would be ideal [20:22:43] it could even try again periodically [20:22:54] but there isn't proper error handling in the email code [20:23:02] Depends on the failure mode. If it says something like "No such recipient" we should perma-disable [20:23:12] But for most other ones, yeah back off and retry later might be nice [20:23:33] it does retry sending them, forever [20:23:50] if it would just give up after a few attempts then we wouldn't even have a problem [20:25:25] Also: it'd be nice if old staff accounts didn't bounce, but like went somewhere (even if it's /dev/null) [20:25:41] (this is always about a staff member) [20:26:30] Disabled 3 accounts, failed jobs slowly clearing out [20:27:04] 4 [20:32:40] 5 [20:33:46] I wish "Leased tasks" was a sortable table [20:33:56] Would be nice to sort by # of failures or lease time [20:36:18] Oh well, it's slowly going down [20:36:24] Gonna take another 40m [20:45:13] twentyafterfour: Other option would be if we could strip the e-mail address from the user [20:45:26] Or does the e-mail job retry independently of a user and will keep trying the same address? [20:53:42] I think it would keep retrying regardless of the user's settings [20:53:54] Yeah, that sucks [20:54:00] Oh well [21:14:20] twentyafterfour: Down to 33 bouncing jobs and falling [21:14:27] Probably gonna be like 1-2 stragglers I haven't spotted yet [21:27:34] twentyafterfour: They don't retry forever, they retry 250 times [21:27:38] That seems...like a lot [21:27:48] I wonder if we could lower that to like...I dunno [21:27:51] Something less crazy [21:29:27] PhabricatorMetaMTAWorker::getMaximumRetryCount() [21:29:30] return 250 [21:29:56] Easy to hack, kinda more annoying if we want to upstream as a config option [22:13:55] we can just hack it, not really a need to upstream [22:19:36] twentyafterfour: Yeah, it's minor enough to maintain ourselves. I think 250 is just an insanely high amount to retry [22:20:07] I need to figure out the series function to learn what the max time a job can wait for [22:20:22] It's something like (num fails * factor) [22:20:28] mod something to figure out the next backoff [22:20:36] yeah it's a long time [22:21:29] Failure Count 118 [22:21:29] Maximum Retries 250 [22:21:30] Retries After 29 m, 59 m, 1 h, 1 h, 2 h, 3 h, 3 h, 4 h, 4 h, 5 h, 5 h, ... [22:21:42] Is that 5h indefinite until we hit max retries [22:21:50] Or does it weave higher/lower? [22:22:03] I'm not sure [22:22:05] It's all kind of complicated for something as simple as e-mail :) [22:22:29] I'd say it should give up after 24 hours [22:23:06] What about an outbound mail outage on a weekend? [22:23:10] * RainbowSprinkles is just thinking aloud [22:23:20] yeah, hmm [22:24:01] I think it goes back to what I said about being able to handle different error types [22:24:02] it should really be handled by the MTA [22:24:10] Like no such recipient bail now [22:24:21] But can't find smtp server retry indef [22:27:26] But like you said, the logic's not there right now :\ [22:28:02] RainbowSprinkles: here's a thing: [22:28:10] ./bin/mail unverify [22:28:26] Unverify an email address so it no longer receives mail. [22:28:28] Oh, that's a better tool [22:28:33] Than disabling [22:28:41] I should go back and rectify those eventually [22:29:03] I think that's relatively new [22:29:10] Yeah, I vaguely remember it being mentioned [22:29:14] But yes, that's a better tool [22:29:20] Because people could always still want their account back [22:29:32] vs disabled is more like spammers and dead role accounts we don't want [22:29:44] (long as they left on good terms :)) [22:35:22] https://phabricator.wikimedia.org/T169380 [22:35:24] ?????? [22:36:02] twentyafterfour: can you please disable that account? [22:36:11] it's spamming Phabricator [22:36:28] https://phabricator.wikimedia.org/people/manage/11371/ [22:43:01] 10Phabricator: Please disable @Monssif365 and delete its .exe/.apk uploaded files - https://phabricator.wikimedia.org/T169381#3396416 (10MarcoAurelio) [22:43:26] oh RainbowSprinkles you're a Phab admin as well [22:43:35] maybe you could do that? [22:43:49] Disabled [22:45:51] RainbowSprinkles: thanks :)