add warning for invalid values

[maryliag]

In the configuration package: for both file config and environment values config, add a diag.warn for invalid/unrecognized values.

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[maryliag]

@maxday would you mind adding a comment here, just so I can officially assign this issue to you?

[maxday]

sorry just saw this, yes please assign it to me :)

[MikeGoldsmith]

@maxday any progress on this? If not, I can take it over 😄

[trentm]

Stealing this issue for discussing/deciding if we should "warn and fallback to default" in all cases.
I think the "from env" and "from config file" cases are different here.

env-based

For env-based SDK configuration, the guidance for env var reading (https://opentelemetry.io/docs/specs/otel/configuration/sdk-environment-variables/#type-specific-guidance) is generally to warn on invalid values and treat the value as not set, or use a default. E.g. "the implementation SHOULD generate a warning and gracefully ignore the setting, i.e., treat them as not set." for numeric envvars.

config file-based

For config file-based SDK configuration the spec says to fail-fast in the Create step (https://opentelemetry.io/docs/specs/otel/configuration/sdk/#create):

When encountering a reference to an SDK plugin component which is not built-in to the SDK, Create MUST resolve the component using Create Component of the PluginComponentProvider of the corresponding type and name used to register, including the configuration properties as an argument. If no PluginComponentProvider is registered with the type and name, Create SHOULD return an error. If Create Component returns an error, Create SHOULD propagate the error.

This SHOULD return an error if it encounters an error in configuration (i.e. fail fast) in accordance with initialization error handling principles.

The Create step handling (in sdk-node) wraps the create() call in a try-catch, and falls back to a warning and a no-op SDK.

So I think the guidance should be:

• create<Thing>FromConfig() methods should throw if the config is invalid, or there is an unknown value
• We don't yet have support for a "PluginComponentProvider" (Register a ComponentProvider #5825, see Marc's PoC for interest: refactor(sdk-node): model built-in exporter resolution on top of PluginComponentProvider spec #6730). I think it is safer to throw when it looks like there is a reference to a custom component name (e.g. a SpanProcessor other than "simple" or "batch"). This avoids a surprise from a fat-finger mistake in a config file.