VRL: Partially fallible blocks can create invalid type definitions

[fuchsnj]

A note for the community

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Problem

A block can contain fallible expressions, which propagates the fallibility up to the entire block. If the fallibility is handled there, that means that any fallible expression in the block can break execution out of the block, effectively making some of the expressions optional. The current type definition assumes all expressions will always execute. This can result in invalid type definitions.

Unfortunately, there is a diagnostic bug preventing an example reproducing this on 0.23.0 (#36)

Below is an example reproducing the issue on 0.22.1, but I believe this is also an issue in both 0.23.0 and master (once the above bug is fixed).

$ type_def(.)
{ "object": {  }, "object_unknown_infinite": { "any": true } }

$ x, err = {.a=1;push(.x,1);.b=2}
"function call error for \"push\" at (15:25): expected array, got null"

$ .
{ "a": 1 }

$ type_def(.)
{ "object": { "a": { "integer": true }, "b": { "integer": true } } }

Version

0.22.1

[fuchsnj]

This also affects arrays and objects, although these will be prevented in the future with: #51

[fuchsnj]

This applies to virtually any expression which contains at least 2 sub-expressions.

Additional example (also on 0.22.1 due to the same bug above)

$ type_def(.)
{ "object": {  }, "object_unknown_infinite": { "any": true } }

$ x,err = {push(.x, 1); false} || {.a = 1}
"function call error for \"push\" at (9:20): expected array, got null"

$ .
{  }

$ type_def(.)
{ "object": { "a": { "integer": true } } }