My instance is pretty low traffic, like <1000 daily page views (excl. crawlers).
However, just by opening the forum home page and doing nothing, I get at least one 429 response, sometimes 2 or 3, and this is before clicking anything.
Searching here on meta the only topic I could find has a high volume and shouldn’t explain what’s happening here.
My instance uses the official installer, but with a subfolder setup. I thought there could be some misconfiguration regarding real user IPs from my reverse proxy to NGINX, but as far as I can tell, IPs are being correctly reported (I can dig this further if it’s still a candidate cause to this issue).
I wouldn’t be too concerned about it, but I’m sometimes facing an issue on chat where when I edit a chat message I don’t get to see the updated content right away and I’m wondering if it’s related to the 429s.
I appreciate any guidance on how to diagnose this, any suggestion is welcome!
Hey Stephen, thanks for taking the time to answer!
I have looked at the reported IPs on active user accounts and they all seem to be correct – mine included. Other people’s IPs are different from each other and all are from different places in my country (Brazil), which is expected. I was considering looking into it in the database and logs, but I didn’t because of this test indicating it may not be the issue.
I’m not using CloudFlare as a proxy, but I did use it in the past – I double checked that the templates/cloudflare.template.yml is commented out.
Now, looking at my app.yml, I see that templates/web.ratelimited.template.yml is also commented out… I wonder if it makes sense to include it to avoid being rate limited? That doesn’t make sense, right?
The 429 response body is “You’ve performed this action too many times. Please wait 2 minutes before trying again.”
I’m still getting those, I understand now that it’s Discourse that’s acting on it, not Nginx, so I’ve tried setting DISCOURSE_REJECT_MESSAGE_BUS_QUEUE_SECONDS: 0.2 (default is 0.1) as I’ve seen in other topic regarding message bus 429’ing but nothing has changed. I appreciate if anyone can point me into the direction of environment variables that may loosen this limit.
I’m also seeing this error on the console.
I wouldn’t be too concerned by either of those issues, the real problem here is that chat messages are not showing up unless I refresh or switch channels: if I switch from a personal chat to another and then back again, only then I can see new messages.
As we just chatted over, this is caused by Unicorn requests queuing up, @renato will adjust the number of Unicorns and report his findings.
Now this is quite bad. What should happen is that after the backoff period the chat will automatically recover and fetch all the messages since last working polling. You don’t see that? If so that is a nasty bug.
Yeah, I didn’t experience this, this may still be something else, I’m not sure. I can see the green dot indicating there’s a new message, but the message itself doesn’t show up, then when I switch channels I can see the new messages and the green notification dot goes away.
I’m rebuilding now with additional workers and I’ll test it further, if this keeps happening I’ll try to collect as many details as I can and report back.
@Falco Reporting back, I can still see 429s on the console and networks tabs.
I can also reproduce the issue of the chat window not updating even chatting with myself: if I send a message, it shows up but the hover controls don’t, then if I switch to another chat and back again, I can edit the message I sent but I have to leave/return to see it updated.
Im doing a big refactor of a lot of network/live update stuff ATM, I expect to merge it somewhere next week, that might improve your issue a lot (unless it’s something else totally unrelated).
I think we have the same issue. Many highly engage chat users reporting they are not seeing messages being sent by others, only there own until they refresh. Is there any solution to this either on front end via dashboard or via the SSH?
That doesn’t make sense, right? 
