context.Context in Configuration APIs—Opportunities for Clarity and Consistency

[mmorel-35]

I’d like to open a discussion about the use of context.Context in configuration-related APIs throughout the OpenTelemetry Collector and its contrib repositories.

Background

This question emerged while I was working on several PRs to improve static analysis and code clarity:

• Enable contextcheck linter in contrib
• Fix contextcheck for exporters
• Enable fatcontext linter in contrib
• Enable fatcontext linter in core
• Enable contextcheck linter in core
• Refactor New{Logs,Metrics,Traces} to remove unused config parameter
• Remove unused context.Context from config methods

While applying tools like contextcheck and fatcontext, I noticed several configuration and instantiation functions accepted context.Context without using it. This inspired me to reflect on whether these parameters are necessary or beneficial in such APIs.

Reasons to Consider Avoiding Unused Context in Config APIs

• Clarity: Including context.Context can suggest that cancellation, deadlines, or request-scoped values are relevant, which is not typically the case for configuration code.
• Simplicity: Removing parameters that are not used can make APIs easier to read and maintain.
• Alignment with Go Practices: The Go standard library and many established Go projects only use context when there is a clear need, such as for I/O or network operations.
• Static Analysis: Tools like contextcheck and fatcontext help identify potential improvements and maintain consistency.

On Future-Proofing and Stability

Some maintainers have pointed out (and I agree from my experience) that changing stable APIs after release can be challenging for downstream users. Stability is important, and we should be thoughtful about changes that could affect published interfaces.

With that in mind, I’m interested in whether the community sees value in establishing a guideline to avoid unused context parameters in configuration APIs—both when updating existing code (where feasible) and in new APIs going forward.

Questions for the Community

• Are there use cases where context.Context brings value to configuration-related methods?
• Would it be helpful to have a guideline discouraging unused context in config APIs, and/or to use static analysis tools to support this?
• What is the best way to balance code clarity and API stability in this area?

I appreciate all the past and ongoing contributions to this project, and I hope this discussion can help us clarify our shared approach for future development.

Thanks!