Description
Describe the bug
When a validation fails because the collector can't find the referenced component, it displays some YAML serialization of valid components instead of their name
Steps to reproduce
Specify a config with a component that isn't included in the collector and validate it (see config later on in report)
% otelcol validate --config=config.yaml
What did you expect to see?
A list of component names as possible values
What did you see instead?
% otelcol validate --config=config.yaml
Error: failed to get config: cannot unmarshal the configuration: 1 error(s) decoding:
* error decoding 'exporters': unknown type: "lorging" for id: "lorging" (valid values: [<component.Type Value> <component.Type Value> <component.Type Value> <component.Type Value> <component.Type Value>])
2024/03/27 11:23:56 collector server run finished with error: failed to get config: cannot unmarshal the configuration: 1 error(s) decoding:
* error decoding 'exporters': unknown type: "lorging" for id: "lorging" (valid values: [<component.Type Value> <component.Type Value> <component.Type Value> <component.Type Value> <component.Type Value>])
Specifically the valid values are listed as <component.Type Value> instead of the actual exporters I have in this custom collector. This custom collector has 5 exporters and <component.Type Value> appears 5 times in the list so it's properly iterating through all the possible processors, it's just not correctly printing their names.
To be clear, the failure of validation is expected, it's the output of that validation failure that is the issue.
What version did you use?
A custom built collector built against 0.97.0 with 5 exporter components.
What config did you use?
This config has an error that it's trying to load the lorging with an extra r component rather than the actual logging component.
receivers:
otlp:
protocols:
http:
exporters:
lorging:
service:
pipelines:
traces:
receivers:
- otlp
exporters:
- logging
Environment
MacOS 13.6.6
Custom collector built using ocb 0.97.0, running go 1.22.1
Additional context
Much like #9855, this is probably caused by changes in #9472, but the changes in #9856 don't fix this, so I'm opening a new issue by request of @TylerHelmuth