Bug #22554
open
Support launching workflows with optional inputs
Added by Brett Smith about 2 months ago.
Updated about 22 hours ago.
Description
source:tools/cluster-activity/cluster-activity.cwl has the following inputs:
inputs:
reporting_days: int?
reporting_start: string?
reporting_end: string?
These are optional because you can provide some subset of them, but it's an error to specify all of them.
You cannot launch this workflow from Workbench with a specified date range:
It should be possible to completely omit inputs just like it is in YAML.
Solution¶
If a field is marked as optional (this looks like "type": ["null", "string"]) then an empty text input field in the interface should be emitted as "null" and not empty string.
- Target version set to Development 2025-03-19
- Target version changed from Development 2025-03-19 to Development 2025-02-26
- Tracker changed from Feature to Bug
If a field is marked as optional (this looks like "type": ["null", "string"]
) then an empty text input field in the interface should be emitted as "null" and not empty string.
- Description updated (diff)
- Target version changed from Development 2025-02-26 to Development 2025-03-19
- Target version changed from Development 2025-03-19 to Development 2025-02-26
- Target version changed from Development 2025-02-26 to Development 2025-03-19
- Target version changed from Development 2025-03-19 to Development 2025-04-02
- Assigned To set to Lisa Knox
- Status changed from New to In Progress
- Status changed from In Progress to New
From standup discussion: for any optional input, if the user did not provide an input, Workbench should set that input to null
in the container request.
Based on the error message, right now it looks like it always uses the empty string. This is valid for string?
but it may not generate the results the user wants. It is definitely not valid for other optional types like int?
here.
I have registered the workflow in question at tordo-j7d0g-ppkb6bq7gc0n6dn. Feel free to play with it. All of the inputs are optional, so you should be able to generate a useful report with the barest minimum of inputs, like reporting_start
and reporting_end
.
- Status changed from New to In Progress
22554-wf-optional-inputs @ e7539f62e021feeeb9c816eba7a86144986eb977
developer-run-tests-services-workbench2: #1485 
- ✅ All agreed upon points are implemented / addressed.
- N/A Anything not implemented (discovered or discussed during work) has a follow-up story.
- ✅ Code is tested and passing, both automated and manual, what manual testing was done is described
- Manually tested by trying to run a workflow with faulty inputs
- N/A New or changed UX/UX and has gotten feedback from stakeholders.
- N/A Documentation has been updated.
- ✅ Behaves appropriately at the intended scale (describe intended scale).
- Intended scale is a single user running a single workflow.
- ✅ Considered backwards and forwards compatibility issues between client and server.
- ✅ Follows our coding standards and GUI style guidelines.
Notes:
- The issue here is that once an input element in the run wf 2nd step form has been focused, its value is getting coerced as a string by redux-form for whatever reason. This happens only where we use the redux-form
<Field />
component. Fixing the coercion would mean replacing the onChange prop, but redux-form uses its own onChange and will overwrite any onChange we try to pass to it. Instead I added a simple algorithm that checks (after form submission) each field to see if it is both nullable && its value is "", and if so, just replace it with null.
- Target version changed from Development 2025-04-02 to Development 2025-04-16
Also available in: Atom
PDF