WebhookProxy | Discord webhooks go brrrrrrr

Just curious, has anyone been seeing a consistent HTTP 500 from the webhook for some reason. Almost every report I’ve sent is going to a HTTP 500 for some odd reason.

2 Likes

500 is internal.

1 Like

me too, and when you add /queue it gets sent to the proxy, but hangs and is never sent to the actual server

2 Likes

yes, with this proxy it returns Http 500 more often than not, switched it out for another proxy (found on the devforum, in a random thread) as a test and didn’t run into this whatsoever

Did you try my url, it uses the same system.
People who complain about Lewis’s system not working, sometimes tell me that it works when they try my URL.
I’m not sure if Lewis has his setup more behind Cloudflare than I do.
https://webhook.newstargeted.com/

3 Likes

doesn’t work for me, both studio and in game

just tried it, works fine, using the proxy relevant to this thread, 9/10 times returns Http 500

4 Likes

Hi everyone, been able to actually sit down and look at this. Apologies for the delay.

The errors that have been seen are due to the proxy hitting the Cloudflare ratelimit of Discord, which is 50 req/s per IP address, which we have recently started exceeding (since the proxy eats requests that are bad, this means that the legitimate request count has started to exceed the ratelimits set by Discord). I have started talks with Discord to try and get the ratelimits increased for the service and try to provide relief in regards to the issue.

In other news, the proxy now handles roughly ~5.5k requests per second, which should be plenty of context for why the issue is occurring now.

I have also posted an announcement on the website. To remedy this temporarily, I have reverted the proxy to the version without the ratelimit ban. If I get a positive response from Discord, I will remove ratelimit bans again.

Cheers, and thanks for all the fish.

5 Likes

Recently I’ve been using your Webhook proxy to send and edit messages that it sends. But I’ve kind of come into a hold of some sorts. So currently you stated that /queue wont work with ?wait = true which I’m using to recieve back the data of the message and get the message ID so I’m able to edit the message later on. And at the same time I want a reliable place to make the messages which I already Rate Limit in my code to be queued in your system.

?wait=true is inherently incompatible with the queue system because it requires the message to actually be sent before you can get a response. The queue system, as the name implies, puts your request into a queue to be dealt with at some point in the future, and sends back an acknowledgement that it’s been queued. There is no workaround for this and I can’t determine what the message ID will be before it has been sent. It is only reliable in the sense that it will send in the future, not that it will guarantee it gets sent immediately. You will have to work out another solution.

Alright thanks for the reply, I’ll think of something to counter this off and I’ll let you know if I have any solutions so other people can use it.