fix(core): ensure proper parsing for yaml/json input types

[MTarek165]

closes #13007

Description

• YAML/JSON nested inputs were passed as Java objects and converted using toString(), which breaks their structure and causes deserialization errors.
• Nested types (maps, collections) now use proper YAML/JSON serialization to preserve structure.
• Ensures consistent and correct YAML/JSON parsing for all input types.

Testing

• Previous tests only covered YAML/JSON provided as plain strings.
• Added test coverage for YAML/JSON inputs passed as Java objects.
• Verified that nested structures serialize and deserialize correctly without losing structure.

[loicmathieu]

I wonder if the same issue didn't exist for the JSON input of you set a JSON document as the input default as YAML is a superset of JSON you should be able to define a defailt like this:

- name: json2
  type: JSON
  defaults: {"some": "input"}

Can you test and if it also fail add the same handling for JSON default?

[loicmathieu]

If I undetrstand it, it can only occurs when the value comes from input defaults as here the value will be deserialized as a Map (as a YAML is a Map).

So I think a more compact implementation may be a oneliner like:

case YAML -> current instandof Map ? current : YYAML_MAPPER.readValue(current.toString(), JacksonMapper.OBJECT_TYPE_REFERENCE);

[MTarek165]

• Not exactly, it can only occurs when passed from subflow, they are passed as Map object, otherwise if a standalone flow using inputs either as default or passed by hand they are json so works properly.
• But regarding check here, I agree, at the end it is map and can be simplified I missed it and will update.

[MTarek165]

So instead of creating subflow to test it, I focus on inputs only so that if I passed yaml as object they must be retrieved as the same object again.

[loicmathieu]

Yeah, test can simplify as long as they reproduce what happens in real case scenario

[MTarek165]

OOPS the check for Collection is actually necessary.

When I removed it and tested with this structure (same as in the issue):

inputs:
people:
- first: "John"
last: "Doe"
- first: "Jane"
last: "Smith"

The same problem appeared again because the value of input people is a List, not a Map , and that case was no longer handled.
In general, even if YAML is Map but YAML input values can be one of three types:

• Map
• List
• Scalar (string, boolean, int, etc.)

since we care about input values so the correct logic should be:

• If the value is a Map or a List, we should return it as-is (because it is already a proper Java object).
• Otherwise, treat it as a scalar: convert to String and parse it normally.
  Because of that, I’m reverting back to the original check that detects both Map and Collection, and I will use List example at test because it is less intuitive.

[MTarek165]

I wonder if the same issue didn't exist for the JSON input of you set a JSON document as the input default as YAML is a superset of JSON you should be able to define a defailt like this:

- name: json2
  type: JSON
  defaults: {"some": "input"}

Can you test and if it also fail add the same handling for JSON default?

I think the same problem would occur with json in case of subflow, i would check and fix if any

[MTarek165]

@loicmathieu

• The same issue was happening for json after just replacing the type for parent/subflow example stated in the issue.
• Now handled it same way as yaml input
• Covered it in tests and ensured all related tests working properly
  Is there remaining something?

[MTarek165]

Everything is ok now