Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Similarly named parameters causing incorrect endpoint binding #16

Open
Exanlv opened this issue Feb 23, 2023 · 2 comments
Open

Similarly named parameters causing incorrect endpoint binding #16

Exanlv opened this issue Feb 23, 2023 · 2 comments

Comments

@Exanlv
Copy link
Contributor

Exanlv commented Feb 23, 2023

'something/:thing/:thing_other' with the following bindings ['::thing::', '::thing other::'] produces something/::thing::/::thing::_other rather than something/::thing::/::thing other::

This is caused by the str_replace replacing the :thing part of :thing_other as well, few fixes I can think of:

  1. Requiring params to also have an ending :, instead of :guild_id it'd be :guild_id: (breaking change for users who specify their own endpoints manually instead of using the constants)
  2. Dont replace :guild_id, instead replace :guild_id/ AND /:guild_id with the appropriate param, not breaking
  3. Setting a priority to params to replace, in the example provided :thing_other would get higher priority and be replaced first. This would still allow weird replacements when you use $onlyMajorParameters but it wouldnt cause issues for the rate limiting buckets as it's consistently weird

Currently, there's no endpoints for Discord that would run into this issue. Low priority.

@SQKo
Copy link
Member

SQKo commented Sep 10, 2023

We actually also have to replace the placeholder symbol, i just found a case where we have to deal with reactions endpoints and a custom emoji needs to be in format name:id, the colon in value will break the binding replacement placeholder

@Exanlv
Copy link
Contributor Author

Exanlv commented Sep 28, 2023

Looks like we'll have to go with number 1 then, unless you see another way to solve it.

Any preference for placeholders if we go that route? {guild_id}?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants