* 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
* 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
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.
Using `after` in the single tests is a bit messy as it runs after all the tests and if one fails sometime it won't run properly.
This approach uses a single `afterEach` hook to clean up all resources created during the tests after each test run.
Also remove `async` from describe functions as it is not supported and can lead to issues
Co-authored-by: Skillz4Killz <23035000+Skillz4Killz@users.noreply.github.com>
* 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>
* Fix optionals for some props in autoModeration.
Also fix some comments to be more clear
* Fix type error in automodActionExecution
* Fix type error in automod.spec.ts e2e test
---------
Co-authored-by: Awesome Stickz <awesome@stickz.dev>
* Migrate eslint and prettier to biomejs
This does NOT include examples/bigbot as it has its own formatter
* Update to biome 1.8.0
* Readd dotenv dev dependency to rest
During a merge it got lost
* Do some code changes & run prettier and eslint
* Fix test:test-type script
* Apply code review suggestions
* update heartbeat interval & add a reason for the specific value
* Fix husky error
* Update to TS 5.5
And use ${configDir}
* Fix test.json tsconfig base
---------
Co-authored-by: Skillz4Killz <23035000+Skillz4Killz@users.noreply.github.com>
* misc: Make the token a required property on the rest manager.
* refactor: Make unnecessarily required properties optional.
* misc: Improve interface for `createBot()` and allow passing in `transformers`/`handlers`.
* fix: Test made redundant by changes still being included.
* fix: Missing non-null assertions.
* fix: Benchmarks failing.
* misc: Remove `cache.requestMembers.pending` as an exposed option.
* style: Switch back to interface approach.
* refactor(rest): remove falsy token check
This is in favour for interaction only bots, which still need rest but cannot provide a valid bot token.
If you want to use rest for your normal bot it should be your own responsibility to pass a valid token.
Further more `applicationId` is now a required property since we cannot extract the id from the token anymore.
* forgot to commit that
* fix error
* make appid optional again
* app id throw error if undefined
* fix test
* fix(rest, types)!: support auditlog reason
Improved the consistency by separating the audit log reason to an optional function parameter.
Also added support for 100% documented reason endpoints.
* missing stuff
* fix this
* fix e3e
* fix(bot,rest,types)!: attachment sending
* apply code suggestions
* forgot to add that
* this should not be there i guess
* maybe spell it right
* actually revert the attachments rename
* Change how method gets passed
* more stuff
* improve function name
