You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The documentation for the default value reads Default value to be used for all values not contained in the mapping table. When unset, the unmodified value for the field will be used if no match is found.
However, if default value is unset and dest is set, the unmodified value is not used - the dest field is missing.
[[processors.enum]]
[[processors.enum.mapping]]
## Name of the field to mapfield = "status"## Name of the tag to map# tag = "status"## Destination tag or field to be used for the mapped value. By default the ## source tag or field is used, overwriting the original value.dest = "status_code"## Default value to be used for all values not contained in the mapping## table. When unset, the unmodified value for the field will be used if no## match is found.# default = 0## Table of mappings
[processors.enum.mapping.value_mappings]
green = 1amber = 2red = 3
Now, I don't think the expected is sensible, but there is no unit test to show the correct expected behaviour, but my recommendation would be to correct the documentation and add a unit test to match the current implementation.
The text was updated successfully, but these errors were encountered:
danielnelson
added
bug
unexpected problem or unintended behavior
docs
Issues related to Telegraf documentation and configuration descriptions
labels
Aug 23, 2019
The documentation for the default value reads
Default value to be used for all values not contained in the mapping table. When unset, the unmodified value for the field will be used if no match is found.
However, if default value is unset and
dest
is set, the unmodified value is not used - the dest field is missing.Version: 0a4d74c
Reproducible:
Configuration:
Expected (based on doc):
Actual:
Now, I don't think the expected is sensible, but there is no unit test to show the correct expected behaviour, but my recommendation would be to correct the documentation and add a unit test to match the current implementation.
The text was updated successfully, but these errors were encountered: