Skip to content

Is there a way to redact parameter values in error messages without suppressing the entire error? #2568

@hasryan

Description

@hasryan

Version: v5.0.0

Apologies if I've overlooked an existing issue or some documented functionality that achieves this, but I've been unable to find a way to suppress parameter values in error messages.

As an example, I sometimes need to JSON-decode arrays to loop over them with range in my template.

{{ range (ds "data" "malformed-array-value" | jsonArray) }}
Value[] = {{ . }}
{{ end }}

When I attempt to render this template with a malformed JSON array of ["foo", "bar" (missing trailing ]) I get the following error:

{
  "time":"<time of error>",
  "level":"ERROR",
  "msg":"",
"err":"renderTemplate: failed to render template <arg>: template: <arg>:5:58: executing \"<arg>\" at <jsonArray>: error calling jsonArray: unable to unmarshal array [\"foo\", \"bar\",: yaml: line 1: did not find expected node content"
}

Looking at what I believe is the code generating the leaf of this error chain, I see it's encoding the input directly in the error message string:

return nil, fmt.Errorf("unable to unmarshal object %s: %w", in, err)

This error message is helpful because it explains the problem and location in template, but it includes the malformed value in the error message which I do not want in my logs in case there's something sensitive in it.

My ideal error would look something like this, showing the location and data source / key with the error but no additional details about the value in that parameter.

renderTemplate: failed to render template <arg>:
  template: <arg>:5:58:
  executing \"<arg>\" at <jsonArray>:
  error calling jsonArray: unable to unmarshal array in datasource \"data\" with key \"malformed-array-value\"

I can direct errors to a file and use the exit code alone to determine success, but the only option I've found to get some additional detail is to use a regex to extract a known safe part of the error message.

** Small side note: I was testing some invalid values to see how it would behave and found ["foo", "bar",] did not trigger an error. I think this is because it's using a less strict YAML parser internally. It's not a huge deal for me but it would be nice to have the option to reject values like this as invalid JSON arrays.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions