api-on-the-fly - part 4 - mutations

[oliver-sanders]

Addresses the "executing mutations" point in #339

Note - *Built atop #382 *
Note - Works with the data types defined in cylc/cylc-flow#3469

Add the ability to run mutations from the temporary Mutations view.

Wraps the mutations view up as a Lumino widget in the workflows view, still a a temporary measure but a good POC.

We could automatically fill in the workflow id field based on the current workflow but I think that'll have to wait for the next phase.

TODO:

• The "Broadcast" mutation doesn't work due to an inconsistency between the server and schema arguments in Cylc Flow. - Fixed in latest commit on the Cylc Flow PR
• Handling of null types needs to improve. - Seems to work now with minor changes
• Tests currently broken awaiting resolution of the previous point. - Fixed
• Covered in debug information. - Sorted

What you should expect to see:

1. Go to workflows
2. Open the mutations view.
3. Pick a mutation from the dropdown.
4. Fill in the form (note workflow id is <user>|<reg>).
5. Press submit.

Example:

From the UI:

In the suite log:

2020-01-24T04:11:05Z INFO - Command succeeded:
	reset_task_states(['*.20191214T1200Z'], state=expired, outputs=[])
2020-01-24T04:11:05Z INFO - Processing 1 queued command(s)
	+       reset_task_states(['*.20191214T1200Z'], state=expired, outputs=[])

Requirements check-list

• I have read CONTRIBUTING.md and added my name as a Code Contributor.
• Contains logically grouped changes (else tidy your branch by rebase).
• Does not contain off-topic changes (use other PRs for other changes).
• Appropriate tests are included (unit and/or functional).
• No change log entry required (why? e.g. temporary view not exposed to users).
• No documentation update required.

[kinow]

I think this must be the last or penultimate PR for AOF in thr UI?? 🎉

[oliver-sanders]

Three bullet points left, but getting close. Auto-completing task names and cycle points will be fun.

[oliver-sanders]

Finally managed to compile peek after manually hacking some of the generated files to pick up the correct environment, something is jiggered in the recording/conversion, meh, screenshots will have to do for now.

[hjoliver]

I know the mutations view is temporary ... but using waiting and succeeded task status (name and icons) for the command status could be a bit confusing. Maybe just changing the wording, something like "command pending" and "command succeeded"?

[kinow]

@oliver-sanders not working on infinite tree right now, so happy to review once the conflicts are solved 🎉

[hjoliver]

LGTM, tests as working.

@kinow I've deconflicted this branch - if you can squeeze in a quick review we can merge it. @oliver-sanders is away today.

[hjoliver]

Note the conflict resolution was not trivial, and I didn't entirely know what I was doing. All in one commit in case @oliver-sanders needs to check it later 741f6f1

[kinow]

Sure thing @hjoliver, reviewing it right now.

[kinow]

Some comments on typos and default parameters, but no blockers I think 👍

[kinow]

Note the conflict resolution was not trivial, and I didn't entirely know what I was doing. All in one commit in case @oliver-sanders needs to check it later 741f6f1

Leaving final sign off to @oliver-sanders so that he can confirm the conflict resolution didn't miss anything, and that there's nothing that needs to be done after my comments ☝️ or should we just merge it now @hjoliver as there will be a part 5 PR anyway?

[hjoliver]

I think we are getting closer and closer to being able to call mutations. Tried to hold a running workflow, but I think the form is not ready to invoke that mutation yet (?).

That definitely worked for me - presumably you used the drop-down list at the top of the page (to choose "hold")?

[kinow]

I think we are getting closer and closer to being able to call mutations. Tried to hold a running workflow, but I think the form is not ready to invoke that mutation yet (?).

That definitely worked for me - presumably you used the drop-down list at the top of the page (to choose "hold")?

🤦‍♂ working as expected! Just hid my old comment.

[hjoliver]

Maybe my rushed conflict resolution attempt - in the hope of getting this in today - was a bit premature!

@oliver-sanders feel free to back out my commit if it's easier for you to do the resolution from scratch. (I think I probably got it right, plus it does pass the unit tests and it tests as working for me, but not sure if you intended to keep some of the earlier "temporary" stuff in, and I confess that some of the "example page" stuff apparent in @kinow 's screenshot above isn't clear to me).

[hjoliver]

Actually, after a bit of head-scratching from myself and @kinow above ... I know the "mutations view" is destined to be a temporary thing, but:

• it's not clear what all the stuff on its front page is for, from "Sample Mutation" down; especially once you get down to the entries for NonNull<List<NonNull<String>>> (required) etc.
• all that stuff also obscures the drop-down list that gives access to all the real, individual mutations (It actually looks like merely a heading, with a small inverted triangle only visible off to the right). Not sure how to make that more obvious....

[oliver-sanders]

Tried to hold a running workflow, but I think the form is not ready to invoke that mutation yet (?)

Mutations should be working. Did you resolve this comment because you got it working? If not if you give me some steps to re-produce I'll take a crack at fixing it.

Just caught up with the comments...

I's not clear what all the stuff on its front page is for, from "Sample Mutation"

The "Sample Mutation" is auto-generated from the schema

• It has one argument for each "type" found in the schema (e.g. CyclePoint and TaskID are both types).
• The purpose of this mutation is for manual testing, it shows every possible form widget the generator can produce so that you can have a play about to check it's working.
• It's basically equivalent to this demo Rose App (only auto-generated).
• This form is useful if you are editing the components and want to evaluate your changes.
• If the form generator encounters a type for which it doesn't have a registered component to render it will fall-back to using a text field, so when you load this form if you look at the console you will see all of the warnings that could possibly come from the combination of the form generator and the current schema.
• At the end there are some nested/compound arguments (e.g. NonNull<List<NonNull<String>>>) for testing compound fields.

[hjoliver]

The "Sample Mutation" is auto-generated from the schema ...

So, we should keep this in somehow (and documented) for use by developers in future. (Development mode only?)

[oliver-sanders]

So, we should keep this in somehow

Yep, somewhere, not quite sure where.

[oliver-sanders]

Maybe my rushed conflict resolution attempt - in the hope of getting this in today - was a bit premature!

Wasn't the easiest merge ever, especially for a non-author! Found a couple of small errors so re-merged diffing against your attempt for validation.

[kinow]

Had a look at the last three commits added. Looking good, re-approving +1

[hjoliver]

@oliver-sanders at least my attempt passed the linter 😁

error: Operator '=' must be spaced (space-infix-ops) at src/utils/graphql.js:153:42:
  151 |  * @returns {Object|Array|undefined}
  152 |  */
> 153 | export function getNullValue (type, types=[]) {
      |                                          ^
  154 |   let ret = null
  155 |   let ofType = null
  156 |   for (const subType of iterateType(type)) {

[oliver-sanders]

at least my attempt passed the linter

The subtle differences between Python and JavaScript make it really horrible to quickly switch between the two.