Ensure local input object is used for step inputs resolution, not the global workflow input object

[mexanick]

When defining expressions or parameter references ($(...) or ${...}) within a workflow step's in section, the parameter context should resolve to the local input object of that specific step (the values passed to the step via source or valueFrom), not the top-level (global) input object of the entire workflow.

The CWL specification defines a parameter context for resolution. Our current implementation in CTADIRAC extension seems to mistakenly use the workflow's top-level inputs object when it should be using the dynamically generated input object specific to the step being executed.

This behavior is problematic because:

• It can lead to unexpected reference errors if a parameter exists in the workflow's global inputs but has not been explicitly mapped to the step's in section.
• It violates the principle of step isolation and explicit data flow, which is a core tenet of CWL. The step should only have access to data that has been explicitly passed to it.

In order to avoid such issues in the future, we should add corresponding tests and ensure the correct parameter context provision for the inputs resolution.

[aldbr]

Is this example reflects correctly what you mean?

# Workflow has a global input called "database_path"
inputs:
  nb_events: string
  user_file: File

# Step definition
steps:
  process_step:
    in:
      input_file: user_file
      # This expression should FAIL because nb_events 
      # wasn't explicitly passed to this step
      config: $(inputs.nb_events)  
    run: some_tool.cwl

[mexanick]

yes, your example should fail, and this should work:

# Workflow has a global input called "database_path"
inputs:
  nb_events: string
  user_file: File

# Step definition
steps:
  process_step:
    in:
      input_file: user_file
      # This expression should work because input_file is locally referenced
      output: $(inputs.input_file.basename.replace(/\.[^/.]+$/, ".newext"))  
    run: some_tool.cwl

[aldbr]

Should see with cwl developers if we can validate expressions without running the workflow.

[natthan-pigoux]

@mexanick , thank you for having noticed that issue in CTADIRAC.

So indeed it was an issue in the CTADIRAC parser since we need to evaluate expressions to have the exact output files name before create the DIRAC job, and workflow inputs were part of the inputs list to evaluate the expressions, which can lead to wrong expression evaluation.

But I don't think we have to test this here, since a user should provide a working workflow, and we don't evaluate the workflow outputs from the cwl but we use ExecutionHooks which define how the outputs should be build.

However I've made a test and cwltool --validate do not evaluate expressions so there is no error displayed in that case. To be sure you need to actually run the workflow.