You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the specification defines the following merge strategy:
The resulting resource will have the Schema URL calculated as follows:
If the old resource's Schema URL is empty then the resulting resource's Schema
URL will be set to the Schema URL of the updating resource,
Else if the updating resource's Schema URL is empty then the resulting
resource's Schema URL will be set to the Schema URL of the old resource,
Else if the Schema URLs of the old and updating resources are the same then
that will be the Schema URL of the resulting resource,
Else this is a merging error (this is the case when the Schema URL of the old
and updating resources are not empty and are different). The resulting resource is
undefined, and its contents are implementation-specific.
This results in resources that are defined using different versions of the OpenTelemetry semantic conventions to be merged into an undefined resource and results in an errors.
Users of libraries that provide resources (via a detector or directly) are often frustrated when they try to merge these resources together or with their own defined resources because the schema URLs differ and the merge results in an error. This is especially frustrating to them given they do not control the upgrade or downgrade of these resources they get from 3rd party libraries and currently have no way to resolve the error.
Given the telemetry schema exist for OpenTelemetry, it should be possible use the telemetry schema to upgrade/downgrade resources for a user (e.g. open-telemetry/opentelemetry-go#3944) and subsequently merge successfully into a single resource.
Existing Implementation
The following is a non-comprehensive survey of what language implementation currently do.
@open-telemetry/dotnet-maintainers, @open-telemetry/python-maintainers, @open-telemetry/javascript-maintainers, @open-telemetry/cpp-maintainers @open-telemetry/erlang-maintainers, @open-telemetry/ruby-maintainers: please feel free to edit the table above to correct any information.
For JS I would say the "Returned Resource" is "Merged resource without a schema returned" even though schema is not supported for resource it is technically true.
For JS I would say the "Returned Resource" is "Merged resource without a schema returned" even though schema is not supported for resource it is technically true.
Currently the specification defines the following merge strategy:
This results in resources that are defined using different versions of the OpenTelemetry semantic conventions to be merged into an undefined resource and results in an errors.
Users of libraries that provide resources (via a detector or directly) are often frustrated when they try to merge these resources together or with their own defined resources because the schema URLs differ and the merge results in an error. This is especially frustrating to them given they do not control the upgrade or downgrade of these resources they get from 3rd party libraries and currently have no way to resolve the error.
Given the telemetry schema exist for OpenTelemetry, it should be possible use the telemetry schema to upgrade/downgrade resources for a user (e.g. open-telemetry/opentelemetry-go#3944) and subsequently merge successfully into a single resource.
Existing Implementation
The following is a non-comprehensive survey of what language implementation currently do.
@open-telemetry/dotnet-maintainers, @open-telemetry/python-maintainers, @open-telemetry/javascript-maintainers, @open-telemetry/cpp-maintainers @open-telemetry/erlang-maintainers, @open-telemetry/ruby-maintainers: please feel free to edit the table above to correct any information.
cc @trask
Proposal
Either:
The text was updated successfully, but these errors were encountered: