VRL downcase: unexpected "this expression is fallible"

[joscha-alisch]

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

The VRL function downcase is marked as infallible in the docs..

However, with this minimal configuration I can reproduce an issue we have in our production config, where the compiler complains:

error[E103]: unhandled fallible assignment
  ┌─ :5:10
  │
5 │ .level = downcase(.level)
  │ -------- ^^^^^^^^^^^^^^^^
  │ │        │
  │ │        this expression is fallible
  │ │        update the expression to be infallible
  │ or change this to an infallible assignment:
  │ .level, err = downcase(.level)
  │

Although we can easily circumvent this issue by adding the !, this does seem like a bug to us.

Configuration

.level = null
if is_null(.level) || !is_string(.level) {
      .level = "unknown"
  }
.level = downcase(.level)

Version

0.23.0

Debug Output

No response

Example Data

No response

Additional Context

No response

References

• Remap: contradicting error messages around merge function #6792 (might be a regression of this one?)

[jszwedko]

Hi @joscha-alisch ,

This has been a common point of confusion. Functions in VRL are infallible only if the types of the arguments are known to match expectations. In this case, downcase expects a string, but it can't be sure that .level is a string. You can also resolve this via something like:

.level = downcase(string(.level) ?? "unknown"))

Where .level will be interpreted as a string or, if it isn't, the string unknown will be used.

[joscha-alisch]

Thanks for the explanation @jszwedko - that's helps!

I think the point of confusion for me was that I would have thought the if-statement would be enough to convince the compiler that .level could indeed only be a string at that point.
Unless I'm missing something - which is not unlikely - it's impossible to get to the downcase-line with a non-string type,right?

[jszwedko]

Hey @joscha-alisch !

Yeah, the issue here is the compiler isn't smart enough, yet, to determine that .level is a string due to the if condition you have. There is some discussion around that in vectordotdev/vrl#91.

Right now only the coercion functions and "assertion functions" (like string) inform the compiler of more exact types.

I'll close this out since I think it is resolved, but feel free to reopen!