-
-
Notifications
You must be signed in to change notification settings - Fork 818
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
fix: batch delegation collapses two requests with different arguments into a single memoized loader #5189
base: master
Are you sure you want to change the base?
Conversation
|
...fieldNodes[0], | ||
alias: undefined, | ||
}; | ||
cacheKey += memoizedPrint(fieldNode); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This breaks print
memoization.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, sorry. Would an acceptable alternative be:
if (fieldNode.selectionSet !== undefined) {
cacheKey += memoizedPrint(fieldNode.selectionSet);
}
if (fieldNode.arguments !== undefined) {
cacheKey += fieldNode.arguments.map((arg) => memoizedPrint(arg)).join(",");
}
d34fb65
to
b8bf584
Compare
🚨 IMPORTANT: Please do not create a Pull Request without creating an issue first.
Any change needs to be discussed before proceeding. Failure to do so may result in the rejection of the pull request.
Description
When using
batchDelegateToSchema
, the cacheKey for fetching a memoized loader is created using either the requested field name (for fields returning scalars) or the field name + selection set (for fields returning composites). When using this in conjunction with non-key arguments (for instance viaargsFromKeys
), those arguments do not effect the cacheKey. Thus, delegating the same field multiple times with different arguments only ever result in one delegation.The proposed fix changes the cacheKey construction. Instead of using only the
selectionSet
of a composite field node, it uses the entire field node (with the alias redacted). This goes for composite fields as well as scalar fields since both of them could be delegating with non-key arguments.It seems to solve the issue (see
cacheByArguments.test.ts
for a test that fails using the old cacheKey construction method, that now passes). However, there might be nuances to delegation that I am missing (for instance, when would there ever be more than one field node infieldNodes
?).Please have a look and see if my proposal makes sense to you.
Related to #5188
Type of change
How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration
Test Environment:
@graphql-tools/batch-delegate
: 8.4.25Checklist: