Project

General

Profile

Actions

Bug #22554

closed

Support launching workflows with optional inputs

Added by Brett Smith about 1 year ago. Updated 10 months ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Category:
Workbench2
Target version:
Story points:
-
Release relationship:
Auto

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:

  • If you leave reporting_days empty, the workflow will fail to start with the error:
    ../../lib/cwl/cwl.input.json:1:227: the 'reporting_days' field is not valid because
    tried int but
    "''" is not int
  • If you specify reporting_days=0, our own cluster activity script will complain that this is mutually exclusive with reporting_start or reporting_end.

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.


Subtasks 1 (0 open1 closed)

Task #22638: Review 2554-wf-optional-inputsResolvedStephen Smith04/03/2025Actions
Actions #1

Updated by Peter Amstutz about 1 year ago

  • Target version set to Development 2025-03-19
Actions #2

Updated by Peter Amstutz about 1 year ago

  • Target version changed from Development 2025-03-19 to Development 2025-02-26
Actions #3

Updated by Peter Amstutz about 1 year ago

  • Tracker changed from Feature to Bug
Actions #4

Updated by Peter Amstutz about 1 year ago

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.

Actions #5

Updated by Peter Amstutz about 1 year ago

  • Description updated (diff)
Actions #6

Updated by Peter Amstutz about 1 year ago

  • Target version changed from Development 2025-02-26 to Development 2025-03-19
Actions #7

Updated by Brett Smith about 1 year ago

  • Target version changed from Development 2025-03-19 to Development 2025-02-26
Actions #8

Updated by Brett Smith about 1 year ago

  • Target version changed from Development 2025-02-26 to Development 2025-03-19
Actions #9

Updated by Brett Smith about 1 year ago

  • Subtask #22638 added
Actions #10

Updated by Peter Amstutz about 1 year ago

  • Target version changed from Development 2025-03-19 to Development 2025-04-02
Actions #11

Updated by Peter Amstutz about 1 year ago

  • Assigned To set to Lisa Knox
Actions #12

Updated by Lisa Knox 12 months ago

  • Status changed from New to In Progress
Actions #13

Updated by Lisa Knox 12 months ago

  • Status changed from In Progress to New
Actions #14

Updated by Brett Smith 12 months ago

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.

Actions #15

Updated by Brett Smith 12 months ago

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.

Actions #16

Updated by Lisa Knox 12 months ago

  • Status changed from New to In Progress
Actions #17

Updated by Lisa Knox 12 months ago

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.
Actions #18

Updated by Peter Amstutz 12 months ago

  • Target version changed from Development 2025-04-02 to Development 2025-04-16
Actions #19

Updated by Stephen Smith 12 months ago

This lgtm!

Actions #20

Updated by Lisa Knox 12 months ago

  • Status changed from In Progress to Resolved
Actions #21

Updated by Peter Amstutz 10 months ago

  • Release set to 78
Actions

Also available in: Atom PDF