aotf: multiple arguments of the same cylc type

[oliver-sanders]

The Play mutation has multiple arguments of the CyclePoint type.

cylc-uiserver/cylc/uiserver/schema.py

Lines 126 to 175 in 57405fc

	class Arguments:
	workflows = graphene.List(WorkflowID, required=True)
	cylc_version = CylcVersion(
	description=sstrip('''
	Set the Cylc version that the workflow starts with.
	''')
	)
	initial_cycle_point = CyclePoint(
	description=sstrip('''
	Set the initial cycle point.
	Required if not defined in flow.cylc.
	''')
	)
	start_cycle_point = CyclePoint(
	description=sstrip('''
	Set the start cycle point, which may be after the initial cycle
	point.
	If the specified start point is not in the sequence, the next
	on-sequence point will be used.
	(Not to be confused with the initial cycle point).
	This replaces the Cylc 7 --warm option.
	''')
	)
	final_cycle_point = CyclePoint(
	description=sstrip('''
	Set the final cycle point. This command line option overrides
	the workflow config option `[scheduling]final cycle point`.
	''')
	)
	stop_cycle_point = CyclePoint(
	description=sstrip('''
	Set the stop cycle point. Shut down after all tasks have PASSED
	this cycle point. (Not to be confused with the final cycle
	point.) This command line option overrides the workflow config
	option `[scheduling]stop after cycle point`.
	''')
	)
	pause = graphene.Boolean(
	description=sstrip('''
	Pause workflow immediately on starting.
	''')
	)
	hold_cycle_point = CyclePoint(
	description=sstrip('''
	Hold all tasks after this cycle point.
	''')

This is correct from a metadata / help text point of view, but it's difficult for the AOTF system to work out which field(s) it should be filling in.

E.g, if I click on a cycle point, the Play mutation will be associated (correct), but which field should it fill in?

• inital_cycle_point
• start_cycle_point
• hold_cycle_point

Presently it is picking initial_cycle_point which is the first item in the list. However, this is invalid for workflows which have previously run as the ICP cannot be specified on restart. [edit, incorrect] Presently it is filling in all fields.

We could swap the order and put the start cycle point first. That would work better in this scenario (the only scenario in which a cycle point would be visible in the GUI).

Or perhaps we should just use a different subclass for these fields so it doesn't trip up AOTF in the first place (do we really want the Play mutation to be an option when clicking on a cycle point, is it intuitive what this will do?).

TODO:

• Placate AOTF
• Remove the hardcoded exception added here

[MetRonnie]

For me AOTF was filling in all the cycle point fields

[oliver-sanders]

Aah, all not just the first, that makes more sense (from the AOTF standpoint), but obvs less sense for the play command!

Corrected OP.