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.
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 graphql node state and remove ghosts filters #4791
fix graphql node state and remove ghosts filters #4791
Changes from all commits
cf43477
4cece6e
7fa56dd
307d1fc
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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'm not too clear on which bits belong to the node and which bits belong to the query?
Is the "state" the node state or the query state?
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.
args
will have the query state to filter againststate
is the node state or data-store node state (if state isn't set in the delta, i.e. with outputs).This ensures we always have a state to filter against (i.e. if we ever wanted to filter deltas by state, then deltas without a state field set can still be filtered by their data-store state)
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.
Cheers, so would this be correct?:
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, that's right.
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.
So if the node has no state (how does this happen?) then we include it in filter results irrespective of whether a query state was specified? Or am I misunderstanding?
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.
It can happen if it's a task definition or something like that.
Correct, as we use the same filter for nodes without states (task defs, family defs)
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.
Could you explain what these two different methods mean?
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.
node
could be from a data-store or a delta-store.Yes, if the first returns
None
or empty string, fetch the state from the data-store...If we want only deltas of specified state(s), then we need to filter out those deltas that don't contain state.
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.
Ok, that makes sense, is this right?:
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.
Correct 👍
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 don't really understand what "ghosts" were, why we had them or why we can dispense of them now?
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.
Ghosts where part of a crude n-window (n=1) prototype... It has long been deprecated, and need to be removed..
It relates to this PR because it was in the part of the filter I had to change.
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.
Ok, so I can test this is still working correctly just be running the UI on a workflow and making sure the N=1 window shows as expected.
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.
(Note the original motivation for this PR was cylc/cylc-uiserver#341 - i.e., custom task outputs not showing up at the UI in real time... which this PR definitely fixes.)
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.
The current n-window implementation is orthogonal to that old prototype. These Ghosts literally weren't used anywhere, but the args were still in the API and in the node filtering.
But sure, test
n=1
if you like :)