-
Notifications
You must be signed in to change notification settings - Fork 271
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
chore(federation): add unit tests and documentation for conditions handling #6325
Conversation
✅ Docs Preview ReadyNo new or changed pages found. |
@goto-bus-stop, please consider creating a changeset entry in |
@@ -46,6 +53,28 @@ pub(crate) enum Conditions { | |||
Boolean(bool), | |||
} | |||
|
|||
impl Display for Conditions { |
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 is mostly for use in tests, though it might help with debugging as well
CI performance tests
|
@@ -1779,7 +1779,7 @@ impl FetchDependencyGraph { | |||
.graph | |||
.node_weight_mut(node_index) | |||
.ok_or_else(|| FederationError::internal("Node unexpectedly missing"))?; | |||
let conditions = handled_conditions.update_with(&node.selection_set.conditions); | |||
let conditions = node.selection_set.conditions.update_with(&handled_conditions); |
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.
Only usage site of update_with()
.
While I was working on #6325, I figured I might as well tackle this related issue quickly. Certain graph and query shapes cause the `FetchSelectionSet::conditions` to be recomputed very, very frequently. Now, they are only recomputed when required. On most plans there is no noteworthy difference. When `OnceLock::get_or_try_init` is stabilised, this will be easier :) <!-- [ROUTER-484] -->
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.
I like always
and never
as an api to conditions!
While I was working on #6325, I figured I might as well tackle this related issue quickly. Certain graph and query shapes cause the `FetchSelectionSet::conditions` to be recomputed very, very frequently. Now, they are only recomputed when required. On most plans there is no noteworthy difference. When `OnceLock::get_or_try_init` is stabilised, this will be easier :) <!-- [ROUTER-484] -->
The
Conditions
structure represents the combined skip/include conditions of a GraphQL query path (and of a FetchDependencyGraphNode).The storage of variable conditions looks inefficient. I tried some quick refactors to make it more efficient, which didn't hugely affect overall planning performance, even on plans that spend a lot of time computing conditions. Perhaps the representation isn't the biggest issue. I think we can still simplify it, though. I might tinker with that if I find some spare cycles in December.
This PR does not change the representation. I only added tests and documentation.
I also flipped the order of the
update_with()
argument. The order of the arguments disagreed with the name of the method. We were not updating the argument at all: we were updatingself
, removing conditions already handled by the argument.