-
Notifications
You must be signed in to change notification settings - Fork 27
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
Invoke mutations to hold, release, and stop workflows #261
Comments
@dwsutherland has already confirmed on Riot that the backend part is ready for the mutations (double thanks!), so we just need to configure ApolloClient and check what/if we need to modify in the |
GraphiQL Docs are the place to learn about the Mutation layout and arguments (Not set in stone, we can change things if desired), however, here are some examples: Mutations-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
And, of course, you can combine them into one docstring/request (although not all combinations might make sense in the internal Cylc command queue). |
Learned a bit more about mutations in our schema while working on the PR's for subscription with the help of @dwsutherland , and also learned about the client side and mutations. I think this will be easier to implement after #280 is merged, as then we will have the |
@dwsutherland today I executed my first mutation in Cylc! It was in GraphiQL, but it's still valid 😬 Not sure if I did something wrong. I was running the workflow However, instead of staying put, with all task held, my workflow shut down almost immediately after the command was received in the server? I thought it would work like Then I tried again, now stopped the hub, stopped the workflow. Restarted the hub, then mutation{
holdWorkflow(workflows: ["five"]) {
result
}
} This time it worked! 😕 ❓ Not sure if you've ever seen anything like this. I couldn't find anything in the suite logs (trying to find something in the job logs, but I have way too many logs for this workflow [EDIT: actually looks like only workflow logs are rotated, the job logs for the same task/cyclepoint are re-created, so I think I only have the last run logs]) |
@kinow - I haven't seen this behaviour before (the shutdown) with mutations, and the log showed that the hold command was queued so IDK (and queries hit the UIS)... We'd need more info to pinpoint where the issue's coming from (?) |
That's what I thought too. I'll probably start working on this issue this week, and will trigger this several other times (both from GraphiQL and via JS). As I use the same workflow over and over, I'm hoping to see the same behaviour again, and then won't execute anything, and try to look at logs/DB to see if there's anything useful. Thanks!!!! |
At a guess, it might be a ZMQ thing? mutation happened at the same time as a data-store update (which will be solved with the sync PR). |
Hmm, that would make sense. We could have a |
Let's just revisit after the data-store sync is in... (as it may not be an issue after that (unless multiple mutations are sent at once)) |
Draft PR ready. @dwsutherland tested three mutations (hold/release/stop), passing variables. Everything worked with no issues on the first tentative 👏 👏 👏 Thanks heaps! I just need to finish testing and polishing the code a bit more, then it should be ready for review. |
Part of #135 , but smaller scope. The PR #257 is updating the toolbar, and leaving only the pause and stop buttons.
The rationale is that the initial implementation is not quite matching the scope of #135. It had some empty/disabled buttons, text, elements, but not functional. #257 will hide the not functional items.
And then this PR will hook up the
click
of the two buttons left behind, and stop or pause the workflow.Having a smaller / simpler issue like this one will help us to prepare the Vue.js + ApolloClient set up, without having to go through all the CSS/styling necessary for the black panels in the sketch (#135).
High Priority, expected for Q1 2020, but the earlier we finish it the merrier.
The text was updated successfully, but these errors were encountered: