refactor(PermissionOverwrites)!: cache-independent resolve #10528
+45
−13
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Please describe the changes this PR makes and why it should be merged:
Resolves #10450.
The linked issue relates to the current cache-dependent behaviour of
PermissionOverwrites.resolve()
, specifically that passing identical parameters to.resolve()
can conditionally pass or fail validation depending on the state of the cache.This isn't ideal, and the function would be better placed resolving the target via
.resolveId()
in a cache-independent manner.This approach doesn't allow for
overwrite.type
to be optional ifoverwrite.id
is a Snowflake, since it would no longer attempt to seek the respective member/role object from the cache to identify it as one or the other. There are two options for how to handle this:overwrite.type
as mandatory, even ifoverwrite.id
is a member object or role object;overwrite.type
as optional ifoverwrite.id
is a member object or role object (current behaviour), but enforce it as mandatory ifoverwrite.id
is a Snowflake.This PR implements the latter approach. It validates
overwrite.id
andoverwrite.type
asGuildMemberResolvable|RoleResolvable
andOverwriteType|undefined
respectively, then:overwrite.id
is a Snowflake, it sets the type of the result tooverwrite.type
, throwing an error if it's not defined;overwrite.id
is a member/role object, it sets the type of the result to the OverwriteType corresponding to that object.overwrite.type
is provided, but doesn't match the type ofoverwrite.id
. This changeset plumps for throwing a validation error if that occurs, since silently overruling the type provided to the function without warning the user could lead to some hard-to-debug quirks.The same cache-dependent
type
behaviour is also present onPermissionOverwriteManager#upsert()
, and the behaviour ofPermissionOverwriteManager#edit()
is also seemingly unnecessarily cache-dependent. Think these should also be updated, but will wait for feedback on the PR so far.Status and versioning classification: