Something about this scenario doesn’t seem right. First of all, I don’t know how I could possibly reply too fast by email, but so it doesn’t even seem like a reasonable thing to block given the latency of email. And how could I reply in any faster than 5 seconds?
AI-generated summary
A user encountered an issue where their email replies were blocked due to replying too quickly. downey questioned the reasonableness of blocking email replies given the latency of email. DeanMarkTaylor suggested that the issue might be caused by email polling and queue processing.
downey agreed that this could be the culprit, but believed the polling queue shouldn’t be the user’s fault. DeanMarkTaylor proposed using the email timestamps to check the frequency of replies. downey found this a sane solution.
sam suggested a simpler solution: queuing the post for processing if a rate limit is hit, and failing after multiple attempts. sam noted that this is a known issue and hosted customers no longer experience it due to immediate email processing. However, erlend_sh explained that this is an infrastructure issue, not a configurable solution.
sam requested that this issue be fixed for version 1.6, and zogstrip provided a GitHub commit link as a potential solution.
I’m guessing the issue is because:
- emails are collected by polling
- several emails are collected via POP3 at the same time
- you sent several emails that when processed in a queue registered as posting too quickly.
6개의 좋아요
Yeah, that seems the likely culprit. But that polling queue shouldn’t be the fault of the user, no? Should email processing be exempted from the rate limit? (Or at least set much higher?)
1개의 좋아요
It should probably use the times on the emails themselves to check the frequency of replies.
6개의 좋아요
Yeah, that sounds sane.
That is super duper hard to do, not feasible at all the way rate limits are implemented.
I think the simplest thing to do here @zogstrip is to queue the post for processing in N (30) seconds if you hit a rate limit, then if it tries N times (3) then fail out.
That way its pretty easy to implement and will not involve a lot of complicated bypasses to rate limits.
4개의 좋아요
Note, we still want to fix this, it is not easy.
Our hosted customers no longer have this problem since emails are processed immediately and not in 5 minute batches.
6개의 좋아요
Is this something that we mere mortals can configure? 
2개의 좋아요
Unfortunately no, since we’re running our own email server in order to get around this, so it’s really a matter of infrastructure, not basic configuration.
3개의 좋아요
@zogstrip I would love to see this fixed for 1.6, it’s quite harsh when it happens.
1개의 좋아요
Ok, let’s try this 
https://github.com/discourse/discourse/commit/51322a46b3fabab11cfa8f29ac4f386d8227aedf
6개의 좋아요
This topic was automatically closed after 3 days. New replies are no longer allowed.