feat(GuildMemberManager): add timeout option to prune()

[pupxrl]

This PR adds support for an optional timeout parameter to the GuildMemberManager#prune() method.

In large guilds, the prune operation can take longer than the default REST timeout (15 seconds), causing it to fail unexpectedly. By allowing a timeout to be passed per-request, developers can handle long-running prune operations without modifying the global REST timeout setting, reducing risk for unrelated API calls.

This change is fully backward-compatible: if timeout is not provided, the method behaves exactly as before.

Example usage:

await guild.members.prune({
  days: 30,
  timeout: 30000, // custom 30s timeout for large guilds
});

Related issue: #10927

Status and versioning classification:

• Code changes have been tested against the Discord API
• Typings were not needed for update
• This PR changes the library's interface (parameter for method added)

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

2 Skipped Deployments

Name	Status	Preview	Comments	Updated (UTC)
discord-js	⬜️ Ignored (Inspect)	Visit Preview		Jul 25, 2025 10:34am
discord-js-guide	⬜️ Ignored (Inspect)	Visit Preview		Jul 25, 2025 10:34am

[almeidx]

Typings need updating

https://github.com/pupxrl/discord.js/blob/2eb8f8a3731166745600fc64e1273430e0418a69/packages/discord.js/typings/index.d.ts#L6205-L6211

[didinele]

I'm not a fan of what this means for our public API and where we take it, I don't think "exceptions" like this are ideal, especially when the design reason for it is something mutable like "this route takes a while"

I'm not sure how future majors of discord.js should address this, but at least for now I feel like we ideally covered this usecase via a REST option

[vladfrangu]

I'm not sure how future majors of discord.js should address this, but at least for now I feel like we ideally covered this usecase via a REST option

Dynamic timeouts would be nice to have in REST.

That said, we should definitely discuss this (and retry count) for either the next major or TSR! It feels like a common use case to have certain calls either be retried or timed out differently (I can also think of sending messages while attaching big files, you wouldn't want the timeout to always be set at minutes)

[didinele]

I agree, but I think we can still support that usecase by taking a callback at the REST level that lets you decide depending on body and whatever else.

I'm not 100% against the per-call approach all together, I'm against adding it to one specific method in this format with the current structure of discord.js 😅

[almostSouji]

concur. route-pattern / body based callback sounds much more scalable and widely applicable than having it as an option on every endpoint and adding an option key (and potentially option where there is none) to the entire high level api interface

[pupxrl]

Noted that this approach is not suggested.

Decided to update typings anyways since I had missed that during the initial PR. 🤷