Skip to content

userAgentAppendix appended multiple times to REST user-agent header each time WebhookClient is instantiated #9421

Closed
@cycloptux

Description

@cycloptux

Which package is this bug report for?

discord.js

Issue description

The PR #9267 introduced an unexpected behavior when instantiating a new WebhookClient, which extends BaseClient, specifying the userAgentAppendix.

Specifically, this part of the BaseClient initiation:

if (options.rest?.userAgentAppendix) {
// Merging the default options when a custom user agent appendix is supplied
// Replaces the discord.js string. Enforce it.
options.rest.userAgentAppendix = `${Options.userAgentAppendix} ${options.rest.userAgentAppendix}`;
}

edits the original options.rest.userAgentAppendix prepending Options.userAgentAppendix. This is fine when instantiating a single Client, but poses problems when instantiating multiple WebhookClients after the initial initiation since the userAgentAppendix value gets longer and longer each time a new WebhookClient() is called, to the point where Discord starts returning 400 errors when sending webhooks through any newly instantiated WebhookClient.

This could be solved by deep cloning options before running:

/**
* The options the client was instantiated with
* @type {ClientOptions}
*/
this.options = mergeDefault(Options.createDefault(), options);

and then moving the above assignment after the deep clone, applied to this.options, but deep cloning though JSON.parse/JSON.stringify and structuredClone breaks complex properties of the rest object, e.g. a custom agent.

Code sample

const clientOptions = { rest: { userAgentAppendix: "loremIpsum/1.0.0" } };
while (true) {
    const webhookClient = new WebhookClient({ url: "https://discord.com/api/..." }, clientOptions);
    console.log(webhookClient.options.rest.userAgentAppendix);
    // userAgentAppendix - and consequently the "user-agent" header - will progressively get bigger: discord.js/14.9.0 Node.js/v18.16.0 discord.js/14.9.0 Node.js/v18.16.0 discord.js/14.9.0 Node.js/v18.16.0 discord.js/14.9.0 Node.js/v18.16.0 discord.js/14.9.0 Node.js/v18.16.0 discord.js/14.9.0 Node.js/v18.16.0 discord.js/14.9.0 Node.js/v18.16.0 discord.js/14.9.0 Node.js/v18.16.0 discord.js/14.9.0 Node.js/v18.16.0 discord.js/14.9.0 Node.js/v18.16.0 discord.js/14.9.0 Node.js/v18.16.0 discord.js/14.9.0 Node.js/v18.16.0 discord.js/14.9.0 Node.js/v18.16.0 discord.js/14.9.0 Node.js/v18.16.0 discord.js/14.9.0 Node.js/v18.16.0 discord.js/14.9.0 Node.js/v18.16.0 discord.js/14.9.0 Node.js/v18.16.0 discord.js/14.9.0 Node.js/v18.16.0 discord.js/14.9.0 Node.js/v18.16.0 [...] discord.js/14.9.0 Node.js/v18.16.0 loremIpsum/1.0.0
}

Package version

14.9.0

Node.js version

18.16.0

Operating system

No response

Priority this issue should have

Medium (should be fixed soon)

Which partials do you have configured?

Not applicable (subpackage bug)

Which gateway intents are you subscribing to?

Not applicable (subpackage bug)

I have tested this issue on a development release

No response

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions