Array/List values are not resolved as expected

[barinali]

Describe the Bug

Array/List values are not resolved as expected. Currently, a variable with a value of ["1", 1, { "test": { "sample": 123 } }] is resolved as below.

The problems I can observe;

• type is Context, but should have been List
• First two entries that are "1" and 1 are omitted, but should have been preserved and resolved accordingly
• isList flag is missing

{
    "name": "arrayValue",
    "provider": [
        null
    ],
    "type": "Context",
    "info": "",
    "entries": [
        {
            "entries": [
                {
                    "atomicValue": 123,
                    "entries": [],
                    "type": "Number",
                    "info": "123",
                    "name": "sample",
                    "detail": "Number"
                }
            ],
            "type": "Context",
            "info": "",
            "name": "test",
            "detail": "Context"
        }
    ],
    "detail": "Context"
}

Steps to Reproduce

1. Create an input/output mapping
2. Enable FEEL expressions
3. Provide a value like ["1", 1, { "test": { "sample": 123 } }]

Expected Behavior

variable-resolver resolves this variable with type=List and isList=true (?) and its entries accordingly without omitting sub-values and their schema.

Environment

• Library version: main, cover-null-variable-type

[nikku]

Due to the nature of its FEEL analyzer (we should switch over to feel analyzer for the actual work type definitions are merged - this means you cannot distinguish different incarnations of values, for both List and standard Context types - you can reproduce your observation outside of list.

foo = 1
foo = "2"
foo = { "a": 10 }
foo = { "b": 20 }

will report as

foo = "2" | { "a": 10, "b": 20 }

Entry keys will be merged.

If we instead want a different user experience (users can "browse through examples of a value"), then let's consider what that experience is, and build our analysis on solid grounds.