Resource attributes for internal telemetry unable to parse numeric strings

[ZY-Ang]

Component(s)

confmap

What happened?

Describe the bug
When a yaml key is supplied dynamically via environment variables, if an environment variable is numeric, e.g. 123, or 1234567890, it will be treated as an integer, and fails to validate to a string here.

Steps to reproduce
Use the otel config below

What did you expect to see?
OTEL is able to boot

What did you see instead?
Please see log output section

Collector version

0.135.0

Environment information

Environment

AWS ECS, but can be reproduciblbe in any environment, with any numeric string, despite being wrapped in quotes/double quotes.

OpenTelemetry Collector configuration

receivers:
  otlp:
    protocols:
      http:
        endpoint: "0.0.0.0:4318"
      grpc:
        endpoint: "0.0.0.0:4317"
processors: {}
exporters:
  debug:
    verbosity: "detailed"
service:
  pipelines:
    logs:
      receivers:
        - otlp
      exporters:
        - debug
  telemetry:
    resource:
      service.name: otel-gateway
      service.version: 'v0.0.0'
      deployment.environment.name: 'test'
      aws.ecs.cluster.arn: '${env:AWS_ECS_CLUSTER_ARN}'
      aws.ecs.launchtype: '${env:AWS_ECS_LAUNCHTYPE}'
      aws.ecs.task.arn: '${env:AWS_ECS_TASK_ARN}'
      aws.ecs.task.family: '${env:AWS_ECS_TASK_FAMILY}'
      aws.ecs.task.id: '${env:AWS_ECS_TASK_ID}'
      aws.ecs.task.revision: '${env:AWS_ECS_TASK_REVISION}'
      cloud.account.id: '${env:CLOUD_ACCOUNT_ID}'
      cloud.availability_zone: '${env:CLOUD_AVAILABILITY_ZONE}'
      cloud.platform: '${env:CLOUD_PLATFORM}'
      cloud.provider: '${env:CLOUD_PROVIDER}'
      cloud.region: '${env:CLOUD_REGION}'
    metrics:
      readers:
        - periodic:
            exporter:
              otlp:
                protocol: http/protobuf
                endpoint: 'https://otel.somedomain:4318'
                timeout: 30000
    logs:
      level: INFO
      processors:
        - batch:
            exporter:
              otlp:
                protocol: http/protobuf
                endpoint: 'https://otel.somedomain:4318'
                timeout: 30000
    traces:
      propagators:
        - tracecontext
        - b3
      processors:
        - batch:
            exporter:
              otlp:
                protocol: http/protobuf
                endpoint: 'https://otel.somedomain:4318'
                timeout: 30000

Log output

2025/10/15 12:30:58 collector server run finished with error: failed to get config: cannot unmarshal the configuration: decoding failed due to the following error(s):
'service.telemetry.resource[cloud.account.id]' expected type 'string', got unconvertible type 'int'
'service.telemetry.resource[aws.ecs.task.revision]' expected type 'string', got unconvertible type 'int'

Additional context

CLOUD_ACCOUNT_ID is in AWS account ID format e.g. 123456789012
AWS_ECS_TASK_REVISION is a numeric string, e.g. 123, 234, ...

Tip

_{React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}

[github-actions]

Pinging code owners:

• confmap: @mx-psi @evan-bradley

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[axw]

@ZY-Ang can you quote the values in the env vars? e.g. set CLOUD_ACCOUNT_ID to "123456789012". That will avoid it being parsed as an integer in the first place.

[ZY-Ang]

@axw

despite being wrapped in quotes/double quotes.

I have additionally tried single quotes, and !!str to no avail

[axw]

@ZY-Ang this worked for me:

CLOUD_ACCOUNT_ID=\"123456789012\" ./bin/otelcorecol_linux_amd64 --config examples/local/otel-config.yaml

...
2025-10-20T10:13:30.938+0800    info    service@v0.137.0/service.go:245 Everything is ready. Begin running and processing data. {"resource": {"cloud.account.id": "\"123456789012\"", "service.instance.id": "79a521c5-7812-4b8d-8355-881af4e6edb4", "service.name": "otelcorecol", "service.version": "0.137.0-dev"}}

EDIT: ah, but that includes quotes in the value. You don't want that.

[mx-psi]

I think the same things I said on #13171 (comment) apply

[ZY-Ang]

Got it, but I am operating in an environment without access to a secondary processor.

Would prefer a no-processor approach.

If push comes to shove, I will use an alphabetical prefix, but not being able to parse numeric-string configs correctly seems like a bug.