Command not registering, Timeout

[ecrocombe]

Description

Registering commands intermittently fails with a timeout error. Have tried changing timeout from 10 seconds to 100 seconds with no difference in results.

Steps to Reproduce

Attempt to Register 27 top-level slash commands, 123 total slash commands. With an average of 3 parameters per command, supporting ~30 Languages. Totals (if my maths is right): (Including Names and Descriptions for each) : 29,520 strings Payload is approx. 1.4MB

Expected Behavior

Commands are registered reliably, everytime.

Current Behavior

The endpoint timesout, with no reponse received.

Screenshots/Videos

No response

Client and System Information

DSharpPlus 5.0.0-nightly-02328 Host: Ubuntu 22.04 Dedicated IP Docker Image: mcr.microsoft.com/dotnet/runtime:8.0-alpine

[DV8FromTheWorld]

We need more information to be able to do anything about this. From initial look, it feels like this is a network problem. This is the first report we have of timeout when registering commands, so I'm inclined to think it is on your side, potentially a network issue with your application host.

[VelvetToroyashi]

I wanted to chime in and elaborate that extensive testing has gone into this issue - profiling, optimizing the library, contacting the hosting provider, etc. The API appears to be spitting HTTP 504 (Gateway Timeout) at this point in time, specifically when posting slash commands.

Networking has been mostly eliminated as an issue from the bot's side both by stress testing the network, and as shown by the stability of other long-running connections (e.g., the gateway, and uploading files). For example, this gif is re-uploaded to Discord on startup, and is about 4.5MB, as compared to the 1.4 or so of the command payload.

Warning, it's pretty flashy. Attachment in question

[DV8FromTheWorld]

How often does this happen? Can we get a replication payload (file) paired with a curl command to test with?

[VelvetToroyashi]

It happens quite often, requiring restarting the bot several times (as D#+ doesn't currently retry 5XX errors). @ecrocombe will have to provide the payload and curl command however

[DV8FromTheWorld]

Before we invest deeply here in investigation, I'd suggest:

• following best practices for retries
• try isolating the issue outside of the library by moving it to cURL
• show that it can be easily reproduced

[ecrocombe]

I'm not very savy with curl, I was however able to obtain a log entry from Fiddler. I have replaced the bots token and cookies with <WITHHELD> Fiddler.txt

[DV8FromTheWorld]

I'm not very savy with curl, I was however able to obtain a log entry from Fiddler. I have replaced the bots token and cookies with <WITHHELD> Fiddler.txt

I have tried this payload ~15 times in Postman (after first clearing out all commands via [] each time to ensure it actually creates the commands). I have seen an average of 5.4 seconds to complete this request every time. Normal range I saw was of 5 - 6.25, with max I have ever saw being 7.12seconds.

For the curious, I had to test this across multiple apps because ~15 times exceeds the amount of commands you're allowed to create/delete/create per day on a single app.

The endpoint appears to be working as intended

[DV8FromTheWorld]

I still cannot repro this or even get close to reproing it from a time-consumed perspective. I am once again left thinking that this is a problem with your individual network connection.

Feel free to open another issue if a consistent reproduction can be found.