3 ms·
It's not your fault. It's actually a PITA to overcome issues like this on a technical level because you have to run something akin to buffer queue, that works
by chrisacky 13y ago
It's not your fault.
It's actually a PITA to overcome issues like this on a technical level because you have to run something akin to buffer queue, that works similar to how "debouncing" works.
The best approach as I have found is to...
- You rate limit events as they happen... So you might let 5 events through (within 10 minutes), and then start to rate limit them by adding each item to a queue which you will merge down every 10 minutes (but that exponentially/incrementally back off each time you exceed the 5 items, so the next queue takes 30 minutes before it's popped, and then 90 minutes... etc)
- So for example, you might have an instant pop from queue where less than 10 events have been triggered within 10 minutes.
- Then if more than 10 events have been triggered, you add each item to a queue, and after X minutes, you pop each item off and send a bulk email.
----
It's a real pain to manage such a system, because your "typical" job server, such as Gearman, doesn't let you add a "delay" on jobs...
Ideally, you'd want to make sure that you ignore any new events for at least X minutes... So you are left with the only option of running another pseudo-queue system just to catalogue all of your throttled events.
Let's talk strategy. How else do you guys handle instant email notifications?... without this spamming issue.
PS. I'm referring to GitHub implementing this strategy, not the OP in case there was any confusion.
- seiji 13y agoThe problem is github makes all notifications STD-level contagious. They broke out "watching" and "staring" a while ago, but they are still very overzealous with notifying everybody about everything. The poster didn't use "send email" API, he was just automatically importing things, and every import triggered emails nonsensically.
- giovannibajo1 13y agoThe problem is that GitHub doesn't really have an import/export API; when you migrate from google code or sourceforge, all issues will appear created and commented from your own account, and at the current date/time. I guess there's a commercial reason for this: http://giovanni.bajo.it/post/60836467126/github-is-missing-import-export-for-commercial-reasons http://giovanni.bajo.it/post/60836467126/github-is-missing-i... I was going to make the same mistake myself (thanks OP!). Is there a workaround?
- plorkyeran 13y ago> Is there a workaround? Not that I know of. I added a note to the README about it sending lots of emails to help others avoid accidentally doing this, though.
- badlogic 13y agoI was about to send a PR for the README, will save a few folks some headaches.
- aaronbrethorst 13y ago> I guess there's a commercial reason for this I doubt that's the case. I bet you that if GitHub were to break out their revenue by plan that the vast majority comes from business plans and GitHub Enterprise. I would be astonished if any of these customers would ever export their dormant repositories for storage. I'm sure that it's just a matter of them prioritizing this vs. the million other things that are on their backlog. As with most other software companies, your best bet would probably be to start emailing their support with requests for it so that they know it's important to the community at large.
- invisible 13y agoMemcache is a pretty good solution.