Skip to content

Refactor internal-logs feature in opentelemetry-otlp to reduce unnecessary dependencies #3263

@cijothomas

Description

@cijothomas

Discussed in #3191

Originally posted by houseme October 3, 2025

Summary

The internal-logs feature in the opentelemetry-otlp crate currently enables "opentelemetry-http/internal-logs". However, since opentelemetry-http itself depends on "opentelemetry/internal-logs", this indirection introduces an unnecessary dependency on opentelemetry-http when using grpc-tonic without default or http features.

Current Behavior

In opentelemetry-otlp/Cargo.toml:

[features]
internal-logs = ["tracing", "opentelemetry_sdk/internal-logs", "opentelemetry-http/internal-logs"]

This forces users to depend on opentelemetry-http even when:

  • Using grpc-tonic transport
  • Not using http or default features
  • Only needing internal-logs functionality

Proposed Change

Directly depend on "opentelemetry/internal-logs" instead:

[features]
internal-logs = ["tracing", "opentelemetry_sdk/internal-logs", "opentelemetry/internal-logs"]

Benefits

  1. Eliminates unnecessary dependencies
    Removes forced opentelemetry-http dependency for grpc-tonic users
  2. Aligns with dependency hierarchy
    Since opentelemetry-http already depends on opentelemetry/internal-logs, this change respects the existing dependency chain
  3. Improves compile times
    Particularly for projects using grpc-tonic with default-features = false
  4. Maintains compatibility
    No breaking changes - all existing functionality preserved

Verification Steps

  1. Check opentelemetry-http/Cargo.toml confirms:
    [features]
    internal-logs = ["opentelemetry/internal-logs"]
  2. Test with:
    opentelemetry-otlp = { version = "*", default-features = false, features = ["grpc-tonic", "internal-logs"] }
    Should not pull opentelemetry-http

Additional Context

This micro-optimization supports the project's goal of maintaining a lean dependency tree, especially important for users carefully managing their dependency footprint in performance-sensitive applications.


Would you like me to submit a PR for this change?
I can prepare a minimal PR updating the feature flag if the maintainers agree this is a welcome optimization.

cc @lalitb @bantonsson

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions