Skip to content

When dispatchPredicate condition evaluates to false, shouldDispatch should return false #138

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

Closed
srinivasankavitha opened this issue Nov 14, 2023 · 3 comments
Milestone

Comments

@srinivasankavitha
Copy link

srinivasankavitha commented Nov 14, 2023

Describe the bug
The default policy when using ScheduledDispatchRegistry is DISPATCH_ALWAYS. However, when a dispatch predicate is set for a data loader, the shouldDispatch method should return false if the condition evaluates to false. Current behavior is that it falls through to the overall DISPATCH_ALWAYS predicate when the dataloader's dispatch predicate evaluates to false: https://github.com/graphql-java/java-dataloader/blob/master/src/main/java/org/dataloader/registries/ScheduledDataLoaderRegistry.java#L219

Is it expected that we always set an explicit overall dispatch predicate (different from DISPATCH_ALWAYS) that would serve as a backup? Currently I have to set it to either DISPATCH_NEVER or some other reasonable default that would eventually be applied so that the individual data loader dispatch predicates get a chance to be applied.

@bbakerman
Copy link
Member

I think you are right - the current code does a fall back to an overall DispatchPredicate if it never returns true but looking at it now on reflection, if there is a specific DispatchPredicate registered for a DataLoader it should take precedence and be the final answer. After all it was specifically set on that data loader.

I am going to change this.

@bbakerman
Copy link
Member

This is now fixed

@srinivasankavitha
Copy link
Author

Great, thank you!

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