* fix(rest): don't resend timed out requests when proxied
When a request to a rest proxy hits requestTimeout, only our side of the
connection gets aborted - the proxy keeps processing the request (often
it's just queued behind a rate limit) and it can still reach Discord.
Resending it executes non-idempotent requests twice. We hit this in
production: a single ticket action created several empty channels because
the channel create kept being resent while the original was waiting out a
rate limit on the proxy.
Timeouts now fail immediately in proxy mode. Only attempts that never
reached the proxy at all (connection refused/reset) are retried, with a
small backoff so a proxy that's restarting isn't hammered in a tight
loop. Direct-to-Discord behavior is unchanged.
Follow-up to #5085.
* feat(rest): support aborting requests that are still queued
* fix(rest): let fetch handle the abort signal
Combine the caller signal with the timeout via AbortSignal.any like
review suggested, so aborting also cancels an attempt already in
flight. Same as nirn - the discord request inherits the incoming
request context, so a disconnect cancels it mid flight too. Dropped
the dispatched flag, not needed anymore. Also wired the signal into
the bigbot rest example off the close event.
* fix(rest): drop redundant abort check, fetch already does it
* tests: Fix broken tests due to sinon fake timers and Node.js v22 microtask behavior
* feat(rest): let users opt into retrying timed out proxied requests
* fix(rest): cap proxy connection retries and reuse the error format
Retrying a request that never reached the proxy was bound by maxRetryCount,
which is Infinity by default, so a proxy that stays down kept every request
alive forever. Cap it at 3 attempts instead.
The proxied path also threw the raw fetch error, so proxy users got a
different error shape than everyone else. Both paths now build the error
through the same helper.
* fix(rest): make the proxy connection retry count configurable
Re-sending a request that never reached the proxy is now bound by
rest.maxProxyConnectionRetryCount (3 by default, and by maxRetryCount when
that one is lower) instead of a hardcoded limit.
Also moves the error builder and the error prototype out of
createRestManager since neither depends on anything in it.
* fix(rest): don't re-send proxied requests that already reached the proxy
A timed out attempt only aborts our side of the connection, the proxy
keeps processing the request and it can still reach Discord, so re-sending
it executes non-idempotent requests twice. proxy.retryOnTimeout opts back
in for setups that deduplicate requests. Connection failures reject right
away, same as a failed fetch does when talking to Discord directly.
Moves the error building into rest.createRequestError so a proxied request
fails with the same message and cause as a direct one.
* fix(rest): re-send proxied requests that never reached the proxy
A failed fetch is only safe to send again when it failed while connecting,
the proxy restarting being the usual case. A socket that dies once the
request is on the wire may have been forwarded to Discord already, so those
keep rejecting right away.
Bound by maxProxyConnectionRetryCount, 3 by default, since maxRetryCount is
Infinity and a proxy that stays down would keep every request alive.
* fix(rest): recognize connect failures on Deno too
Deno puts no code on the errors fetch throws, the only place the phase the
request failed in shows up is the message, so match on that as well.
* fix(rest): go off the phase a request failed in, not the error code
Node.js names the syscall that failed, so matching on that covers every
reason a connection could not be established (refused, host or network
unreachable, dns) instead of the few codes that were listed, and it is
read or write once the request is on the wire. Bun reports a code of its
own and Deno only says it in the message, so those two keep their own
check.
* fix(rest): never re-send once an error says the request went out
A connection that dies while it is carrying the request is reported in
terms of that request, and a runtime can wrap that in the wording for a
failure to connect, which used to read as never having sent anything.
Looking for it first, and over the whole chain, settles those.
Also drops the codes and wordings that were guesses. What is left is what
node, bun and deno were seen to report, with the node ones kept as a
fallback for a runtime that borrows the code without the syscall.
* fix(rest): release cancelled requests and gate proxy re-sends behind one option
Cancelling a request only settled the caller. The entry stayed in the queue,
spent a rate limit slot and reached fetch with an aborted signal. The waiter is
spliced out of `waiting` now, `Queue.makeRequest` stops before pushing to
`pending` when the signal fired while it waited for a slot, and `processPending`
drops an entry whose caller gave up before anything is spent on it.
`processWaiting` cleans up when its loop ends, otherwise a queue whose waiters
were all cancelled never schedules its own deletion.
In proxy mode an abort landing while the response body was being read was
swallowed by the `null` fallback and came back as a successful empty response. A
read the abort killed rejects now, one that finished is still returned, the same
way the queued path keeps a result that arrived before the signal fired.
`proxy.retryOnTimeout` becomes `proxy.retryRequests` and covers every attempt
that failed without producing a response. Telling a failure to connect apart
from a connection that died carrying the request meant reading syscalls, error
codes and error text from three runtimes, and it could never be more than a
guess: fetch does not say which phase a failure happened in, and a wrong guess
re-sends a request the proxy already has. So that block is gone and the caller
decides, the same way it already did for timeouts. One `retryCount` bounded by
`maxRetryCount` and `maxProxyRetryCount`, so alternating failures can no longer
hand out more re-sends than the cap allows.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix(rest): give a proxy that is restarting time to come back
Three re-sends 250ms apart is 750ms of patience, which is sized for a blip
rather than for the case it was added for. A container being restarted or
redeployed is not back in that time, so the budget ran out before the proxy was
reachable again.
Each further attempt now waits 250ms longer than the one before it, and the
default count is 15, so the ladder spans about 30 seconds. Stepping up rather
than doubling keeps the gaps small enough to notice the proxy coming back
instead of sleeping well past it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* refactor(rest): move the proxy re-send delay onto the manager
It was a module level constant sitting next to maxProxyRetryCount's own limit, so it is a manager field now like the counts it goes with, and the tests set it to 0 instead of really waiting out the backoff.
* Update packages/rest/tests/unit/manager.spec.ts
Co-authored-by: Fleny <Fleny113@outlook.com>
* Run biome
---------
Co-authored-by: Fleny <fleny113@outlook.com>
Co-authored-by: Awesome Stickz <38146668+AwesomeStickz@users.noreply.github.com>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
* refactor(rest)!: rename rest.editBotMember() to rest.editCurrentMember() to be consistent with rest.getCurrentMember()
* refactor(type)!: rename ModifyCurrentMemberOptions to ModifyCurrentMember to be consistent with other types
* feat(rest): add request timeout feature to manage request retries
* fix(rest): avoid calling Node-only Timeout.unref() on non-Node runtimes
* fix(rest): use try/catch for fetch to guarantee a Response on the success path
* refactor(rest): use AbortSignal.timeout and retry proxy requests on timeout
* refactor(rest): simplify timeout detection and use .catch() in proxy path
* refactor(rest): move isTimeoutError helper to bottom of file
* Update permissions for community invites
Use payload_json for invite creation with file upload
The TODO in INVITE_CREATE is to be done after #4436 gets merged as it splits the transformer logic between gateway and the normal invite object, placing the event transformation code in the event itself
* Community invites breaking changes
* fix(rest): Use Retry-After header for retrying requests
According to discord docs: Your application should rely on the Retry-After header [...] to determine when to retry the request.
* also use in processHeaders()
---------
Co-authored-by: Awesome Stickz <kiran121102@gmail.com>
* api-docs: Community Invites
Add support for invites that gives roles to users.
Add support for target users on invites.
Sort-of unrleated change required: `restManager.makeRequest` `resolve` function had to changed or else the `getTargetUsers` would hang forever due to a JSON parsing issue.
* fix type error & add bot helpers
* fix(rest)!: Remove calculateBits from changeToDiscordFormat
The rest manager currently has to assume that request bodies that have "permissions", "allow", "deny", "defaultMemberPermissions" fields are always meant as a permissions.
If these are not, for user error or future discord changes, this will break.
Also Discord expects these as strings, and discordeno does not abstract too much from the discord api, so it doesn't really makes sense for us to accept PermissionStrings[], the user should call calculateBits themselves, there is an argument to be made about accepting bigints since these are bitfields but that's another discussion.
* Channel.permissionOverwrites use PermissionStrings
For the transformed type we can keep the fact that it uses PermissionStrings
* Fix e2e test
* remove comment
Queues currenly suppress errors, making it very hard to figure out if there is a parse error for example
This fixes it as it add debug logs and passes the error object along with the rejection in sendRequest and does reject the promise in the queue instead of silently ignoring it
Currently if a queue is pending deletion or waiting to refill its ratelimit will keep the process alive, this is not ideal for scripts like command deployment ones
This does not impact the functionality of the queues in any way, just allows the process to exit if nothing else is pending in which case you would be loosing the ratelimit information anyway
I prefer semicolors, they also help avoiding certain pitfalls in JavaScript/TypeScript, such as the following code sample:
```js
const xyz = "test"
(something.else as string) = "another"
```
This results in a TypeError: "test" is not a function, this is because js thinks we are trying to call the string "test" as a function.
To fix this it requires a `;` somewhere before the `(`, such as `;(something ... ` which in my opinion is ugly and less clean overall.
* fix(rest): Always encode URI component in routes
Instead of using the implicit behavior of `fetch` and `Request` we do it explicitly in the routes.
* Add checks for numbers and digits-only strings
* Add option to disable uri encode
The typedoc config is now only in the top-level config file instead of also being one per package
and all internal APIs are now marked as private so typedoc won't generate documentation for them, however we still need to export them to avoid typedoc warnings
The new internal APIs that are exported, since are marked as `@private` can have breaking changes without notices
* fix(types)!: Split and fix discordeno.ts
* fix some mistakes
* remove now not needed @ts-expect-error
* Apply code review suggestions
* Fix test type errors
* Revert "Apply code review suggestions"
This reverts commit 7a0cea84b3.
* Restore some of the changes from the revert
---------
Co-authored-by: Link <lts20050703@gmail.com>
* Remove incorrect, reorder and fixes in channel
- Updated comments to be more clear
- Remove `Channel.newly_created`, doesn't seem to exist in the api docs
- Fix nullability for some fields
- Remove DiscordActiveThreads, DiscordArchivedThreads and DiscordListActiveThreads as they don't seem to match anything in the api
* Add back DiscordListActiveThreads but under Guild
and fix type errors
* Update packages/types/src/discord/channel.ts
Co-authored-by: LTS (Link) <lts20050703@gmail.com>
* Revert newly_created removal
* Apply suggestions from code review
Co-authored-by: LTS (Link) <lts20050703@gmail.com>
---------
Co-authored-by: LTS (Link) <lts20050703@gmail.com>
* Add lobby support
* Fix CI
Apparently for extends a bot was a LobbyMember since both had
a required id property and even if LobbyMember had other properties
as well that did not matter
* update LobbyMember flags to use ToggleBitfield
Fleny