Not possible to dynamically pass nullable inputs from parent flow to subflow

[rybandrei2014]

Describe the issue

Hello team,

I have a flow that triggers subflow via Subflow task

id: TEST_NULL_ZPRACOVANI
namespace: csutrf
inputs:
- id: integerNull
  type: INT
  required: false
labels: []
tasks:
- id: TEST_NULL_1_subflow
  type: io.kestra.plugin.core.flow.Subflow
  namespace: csutrf
  flowId: TEST_NULL_1
  inputs:
    integerNull: "{{ inputs.integerNull }}"
concurrency:
  limit: 1
  behavior: CANCEL

id: TEST_NULL_1
namespace: csutrf
inputs:
- id: integerNull
  type: INT
  required: false
labels: []
tasks:
- id: log1
  type: io.kestra.plugin.core.log.Log
  message: "{{ inputs.integerNull }}"

I need to pass input variable from parent flow to the subflow. It works fine until the value is null, when I trigger parent flow with input that has flag required = false. The Subflow task throws the following error

integerNull: Invalid input for integerNull, For input string: "", but received `` 

I tried to modify the expression

"{{ inputs.integerNull }}" -> "{{ inputs.integerNull ?? 'null' }}" 

But it also throws an error

integerNull: Invalid input for integerNull, For input string: "null", but received null

Is it possible to somehow pass an input with a null value to the subflow?

P.S.: It's also not possible to achieve with TemplatedTask as it supports only Runnable tasks

Environment

• Kestra Version: 0.18.4

[loicmathieu]

This is not specific to subflow or INTEGER inputs, if a variable is null, our expression engine (Pebble) will return the empty string.
We may be able to do something about it for some input types but not for STRING.

[rybandrei2014]

Hello @loicmathieu thank you for the reaction. I understand that Pebble expression is evaluated as string and in that case type erasure is happening there. So in order to pass nullable inputs from parent flow to the subflow, we need to accept these inputs in our subflow as STRING type and work around type erasure happening there.

[loicmathieu]

@rybandrei2014 it may be a work around yes.
We also may be able to do something about it but it would need careful investigation for backward compatibility