[pkg/ottl] Add Coalesce converter for first-non-nil value selection

[57Ajay]

fixes #46847

Description

Adds a Coalesce converter to OTTL that returns the first non-nil value from a list of arguments.

OTTL currently has no way to express "use the first non-nil value from a set of candidates" in a single statement. Users who need to resolve a canonical attribute from multiple possible sources must write multiple chained set statements with increasingly complex where clauses. This is verbose, ordering-dependent, and scales poorly.

Coalesce solves this:

# Before: 3 statements, fragile ordering
- set(attributes["user"], attributes["user.id"]) where attributes["user.id"] != nil
- set(attributes["user"], attributes["enduser.id"]) where attributes["user"] == nil and attributes["enduser.id"] != nil
- set(attributes["user"], "unknown") where attributes["user"] == nil

# After: 1 statement
- set(attributes["user"], Coalesce([attributes["user.id"], attributes["enduser.id"], "unknown"]))

Implementation

• Registered as a standard OTTL Converter with []ottl.Getter[K] parameter (same pattern as Format).
• Iterates getters left to right, returns the first non-nil result.
• Returns nil if all values are nil.
• No side effects, pure function, bounded execution — consistent with OTTL function design principles.
• No grammar or parser changes.

Testing

Unit tests (func_coalesce_test.go): 13 test cases covering first-value-wins, nil-skip-to-second, nil-skip-to-third, all-nil, single-arg, int/bool/float type preservation, short-circuit evaluation (does not call getters past the first non-nil), getter error propagation, and factory validation (empty args, wrong type).

E2e tests (e2e/e2e_test.go): 3 test cases exercising Coalesce through the real OTTL parser — first-arg-wins, skip-nil-pick-second, all-nil-pick-literal.

Live collector test: Built otelcontribcol, ran the transform processor with 5 Coalesce statements against a real OTLP/HTTP log request. All 5 produced correct output:

-> test1: Str(alice)       # first arg non-nil
-> test2: Str(bob-legacy)  # first nil, second non-nil
-> test3: Str(fallback)    # all paths nil, literal wins
-> test4: Str(alice)       # single arg
-> test5: Int(42)          # first nil, int value wins

[57Ajay]

/rerun

[57Ajay]

I don't know how file .chloggen/fix_gcp_snake_case.yaml started to give error, as it was added when i fixed issue #46588 where component name googlecloudlogentry_encoding was correct, now i guess it's name has been changed to google_cloud_logentry_encoding.
#46588 changes: https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/46588/changes

[MohamedElDegwi]

Hi @57Ajay, thanks for working on this. I've few questions I'd appreciate if you could clarify.

Isn't having multiple statements for different semconvs a migration problem not an ottl one? If understand this correctly, the growth of ottl statements is intended as alert of migration needed, so If I have 3 statements to cover canonical.user this is an indication that I need to sync/update my setup?

Do you have any use-case that require this function? From what I see, set + where is explicit, readable, and capable enough. See PR#46443 as an example.

Sorry If I've been bit skeptical haha :)

[57Ajay]

Hi @57Ajay, thanks for working on this. I've few questions I'd appreciate if you could clarify.

Isn't having multiple statements for different semconvs a migration problem not an ottl one? If understand this correctly, the growth of ottl statements is intended as alert of migration needed, so If I have 3 statements to cover canonical.user this is an indication that I need to sync/update my setup?

Do you have any use-case that require this function? From what I see, set + where is explicit, readable, and capable enough. See PR#46443 as an example.

Sorry If I've been bit skeptical haha :)

Thanks @MohamedElDegwi, fair question.
The semconv migration case was just one example -- you're right that it could signal a migration need. But the more common use case is permanent multi-source fallback, where you receive data from heterogeneous sources you don't control (different SDKs, different systems) and need one canonical attribute for downstream querying. There's nothing to migrate in that case -- the diversity is the long-term reality.
On set + where -- it works for few candidates such as 1 or 2, but with more like 3+ the where clauses grow quadratically (each must check all prior candidates were nil), and reordering them silently changes behavior. Coalesce makes the intent explicit in one statement. It's the same reason SQL has COALESCE and JavaScript has ?? -- the pattern is common enough to warrant a primitive.
also Will remove the stale chloggen file in the next push.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 14 days.

[edmocosta]

Thank you for working on this, @57Ajay. LGTM!

[57Ajay]

fixed with @edmocosta suggestions

[otelbot]

Thank you for your contribution @57Ajay! 🎉 We would like to hear from you about your experience contributing to OpenTelemetry by taking a few minutes to fill out this survey. If you are getting started contributing, you can also join the CNCF Slack channel #opentelemetry-new-contributors to ask for guidance and get help.