Unable to use file directives to include the contents of individual processors v0.109.0

[arielvalentin]

Describe the bug

In versions prior to 0.109.0 we were able to include the contents of a processor definition using a file directive, e.g.:

transform/redaction-rules: ${file:redaction-rules.yaml}

However, when attempting to validate the configuration v0.109.0, it fails with the following error:

error decoding 'processors': error reading configuration for "transform/redaction-rules:": unexpected sub-config value kind for key:transform/redaction-rules value:{map[error_mode:ignore....] error_mode: ignore
} kind:struct

Steps to reproduce

What did you expect to see?

I expect the behavior to remain the same, for the validation to succeed, and the collector to start up.

What did you see instead?

The collector and/or validation commands fail with an error error decoding 'processors': error reading configuration for "transform/redaction-rules:"

What version did you use?

v0.109.0

What config did you use?

service:
  pipelines:
    traces:
      receivers:
        - otlp
      processors:
        - batch
        - transform/redaction-rules
      exporters:
        - logging
        
# The pipeline details
receivers:
  otlp:
      http:

processors:
  transform/redaction-rules:
    ${file:redaction-rules.yaml}

  batch: {}

exporters:
  logging:
    verbosity: detailed
    sampling_initial: 1
    sampling_thereafter: 1

 # transform/redaction-rules
 ---
error_mode: ignore
trace_statements:
- context: span
  statements:
    - |-
      set(attributes["http.target"],
      SHA256(attributes["http.target"]))
      where attributes["http.target"] != nil
    - |-
      set(attributes["http.url"],
      SHA256(attributes["http.url"]))
      where attributes["http.url"] != nil
    - |-
      set(attributes["url.full"],
      SHA256(attributes["url.full"]))
      where attributes["url.full"] != nil

Environment

Additional context

[mx-psi]

Thanks for reporting! I wrote a more minimal repro:

Minimal repro (click to expand)

# config.yaml
receivers:
  nop: ${file:nop.yaml}

exporters:
  nop:

service:
  pipelines:
    traces:
      receivers: [nop]
      exporters: [nop]

# nop.yaml
{}

Output:

❯ ./bin/otelcorecol_linux_amd64 --config config.yaml 
Error: failed to get config: cannot unmarshal the configuration: decoding failed due to the following error(s):

error decoding 'receivers': error reading configuration for "nop": unexpected sub-config value kind for key:nop value:{map[] # nop-config.yaml
{}
} kind:struct
2024/09/12 10:52:53 collector server run finished with error: failed to get config: cannot unmarshal the configuration: decoding failed due to the following error(s):

error decoding 'receivers': error reading configuration for "nop": unexpected sub-config value kind for key:nop value:{map[] # nop-config.yaml
{}
} kind:struct

This happens because of a bug on confmap.Conf.Sub that is leaking the internal representation of confmap.Conf. This happens since #10897 so I expect this is reproducible on v0.108.0 also. I will file a PR to fix this for v0.110.0.

In the meantime, an ugly but effective workaround should be to go one level higher/lower since the bug is specific for transclusion of a whole component config. For example, I believe the following should work:

processors:
  transform/redaction-rules:
    error_mode: ignore
    trace_statements: ${file:file-with-only-the-rules.yaml}

[arielvalentin]

Thanks for the prompt attention and fix for this @mx-psi !

As I mentioned in slack, we are stuck on 104 for performance regressions. We could try the workaround but it would require some additional code changes on our side since we generate our redaction rules from an external classification source.

I want to say again that it would be helpful to us if a patch release could include your fix (11157) sooner than v0.110.0. Not sure if that would be possible.

@bogdandrutu was helping us workaround some of the ocb issues where we now how to specify the providers and pin them to specific versions so I am hoping he could help us get a patch release out for this too.

[kago-dk]

I also ran into this issue, so I share @arielvalentin desire for a patch release. It was an area that was also broken in 106.1 (#10799).

[arielvalentin]

@mx-psi suggested a workaround. I was able to add a comment with an invalid expansion key and the confmap was able to load the file like this:

 # ${transform.redaction.rules}
 ---
error_mode: ignore
trace_statements:
- context: span
  statements:
    - |-
      set(attributes["http.target"],
      SHA256(attributes["http.target"]))
      where attributes["http.target"] != nil
    - |-
      set(attributes["http.url"],
      SHA256(attributes["http.url"]))
      where attributes["http.url"] != nil
    - |-
      set(attributes["url.full"],
      SHA256(attributes["url.full"]))
      where attributes["url.full"] != nil

The runtime error went away. I am going to try this in our canary deployments and report back my results.