ReAct agent (only?): workflow [null] that gets passed via "Extra Workflow Inputs" as string, comes out as "null"

[Morriz]

Bug Description

What the title says.

To Reproduce

null_passing_to_sub_workflows.json

1. trigger workflow
2. observe that the calling workflow's value for $json.test is [null], but in the receiving workflow it is now "null".

Expected behavior

The ReAct agent to not mess with values. I hope the recent refactoring of this agent has fixed this, but maybe my bug report is just in time to get a fix shipped ;)

Operating System

docker

n8n Version

1.68.0

Node.js Version

docker

Database

SQLite (default)

Execution mode

main (default)

[Joffcom]

Hey @Morriz,

We have created an internal ticket to look into this which we will be tracking as "GHC-454"

[jeanpaul]

Hi @Morriz

Can you provide more information here as well? It's unclear what you mean by "test output workflow". A workflow JSON with minimal working example would be appreciated.

Also, we recommend users to move away from ReAct agents, and use Tools agents as much as possible; ReAct agents are not as reliable.

[Morriz]

@jeanpaul ?? I find react agents to be MORE reliable and I have switched to that from tools agents.

I will provide my workflow here in a bit

[Morriz]

@jeanpaul I never saw I did not correctly add the test workflow files in my OP, but have added it now.

[jeanpaul]

Hi @Morriz, I've looked at your workflows, and I'm not exactly sure what I should observe. When running this, I see that the variable test, with value null, is being transformed into a string (because you explicitly type it as string), and that means that the if-node in the sub-workflow is entering the true branch, because the test variable is, indeed, not empty.

I've used the following workflow to make it a bit easier, and to keep everything in one workflow (be advised, you need to save it before you can actually call the self-contained sub-workflow):

react_agent_only_previous_null_that_is.json

[Morriz]

I would assume that n8n deals with passing on keys that are given undefined values correctly. (It seems messy in the traces, as I see [undefined] as well as [null] values, making me think who uses nulls? Not me.) Maybe I am mistaken and got lucky so far. (To me it only seems to be an issue in this setup.)

My point is: how can we detect in such setups that we got an empty value passed in the sub-workflow? Can you help me solve that use case?

[Morriz]

@jeanpaul I tested it again and this bug still holds. Your assumption that an undefined or null value being passed to another workflow via "Extra Workflow Inputs" will be cast by the UI's formatter (string in this case) is correct, but this should not happen as INSIDE a workflow this never happens. We should be safe to assume that any primitive values such as undefined or null are passed on as-is, and not piped through the formatter.

Unfortunately "Extra Workflow Inputs" does not offer raw json so we can't work around this issue, and I think this needs work by the team to make sure the props passing paradigm holds.

[jeanpaul]

The team is working on other improvements to sub-workflows, and they'll take this one into account too.