Tracking issue for `configoptional.AddEnabledField` feature gate

[mx-psi]

Feature gate name

configoptional.AddEnabledField

Description

Allows to configure any field using a configoptional.Optional with enabled. For example, the following configuration becomes valid:

receivers:
  otlp:
    protocols:
      grpc:
        enabled: true

exporters:
  nop:

service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [nop]

and is equivalent to:

receivers:
  otlp:
    protocols:
      grpc:

exporters:
  nop:

service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [nop]

which also remains a valid way of configuring this.

Issues blocking alpha to beta transition

• Get usage testing for the use cases we currently have in mind:
  • confighttp keepalives,
  • confighttp Cookies section (PoC)
  • exportehelper batching from elasticsearchexporter and datadogexporter

Issues blocking beta to stable transition

• Make sure that dependent products (e.g. OpenTelemetry Helm Chart) can work correctly after this change
• Use configoptional for existing configuration sections that have an enabled field

History

Version	Status	PR
v1.45.0/v0.139.0	Introduced at alpha level	#13995
v1.46.0/v0.140.0	Promoted to beta level	#14136

Tip

_{React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}

[yurishkuro]

I am not seeing motivation / justification in the description. Why is this needed? It adds redundancy in the configuration. Does it unblock any scenarios not already possible?

[mx-psi]

I am not seeing motivation / justification in the description. Why is this needed? It adds redundancy in the configuration. Does it unblock any scenarios not already possible?

@yurishkuro Currently a configoptional.Optional that is enabled by default cannot be disabled, that's the main use case for this

[yurishkuro]

@mx-psi do you mean

receivers:
  otlp:
    protocols:
      grpc:

and

receivers:
  otlp:
    protocols:

are equivalent? I thought that was the point of WithDefault() constructor, it only takes effect if the user config specifies the element, otherwise the value remains None. If it's not this example, than which one falls in your category?

Basically, I am skeptical about elevating enabled, a business function, to Optional, a structural building block. The individual configs can always add enabled flag to themselves if they need this edge case.

[mx-psi]

@yurishkuro

No, that's not what I mean, I think the best example are keepalives in configgrpc. configgrpc.ClientConfig has a Keepalive field that is a configoptional.Some by default. That means that there is no way to say "I don't want to have keepalives" through the current configuration: it does not matter what you set keepalive to, it will remain enabled

[mx-psi]

CookiesConfig and other empty sections can work fine with this:

diff for CookiesConfig

diff --git a/config/confighttp/client.go b/config/confighttp/client.go
index 41e5dd1b5..f6a2b946c 100644
--- a/config/confighttp/client.go
+++ b/config/confighttp/client.go
@@ -101,7 +101,7 @@ type ClientConfig struct {
 	// If not set or set to 0, it defaults to 15s.
 	HTTP2PingTimeout time.Duration `mapstructure:"http2_ping_timeout,omitempty"`
 	// Cookies configures the cookie management of the HTTP client.
-	Cookies CookiesConfig `mapstructure:"cookies,omitempty"`
+	Cookies configoptional.Optional[CookiesConfig] `mapstructure:"cookies,omitempty"`

 	// Enabling ForceAttemptHTTP2 forces the HTTP transport to use the HTTP/2 protocol.
 	// By default, this is set to true.
@@ -116,9 +116,7 @@ type ClientConfig struct {

 // CookiesConfig defines the configuration of the HTTP client regarding cookies served by the server.
 type CookiesConfig struct {
-	// Enabled if true, cookies from HTTP responses will be reused in further HTTP requests with the same server.
-	Enabled bool `mapstructure:"enabled,omitempty"`
-	_       struct{}
+	_ struct{}
 }

 // NewDefaultClientConfig returns ClientConfig type object with
@@ -266,7 +264,7 @@ func (cc *ClientConfig) ToClient(ctx context.Context, host component.Host, setti
 	}

 	var jar http.CookieJar
-	if cc.Cookies.Enabled {
+	if cc.Cookies.HasValue() {
 		jar, err = cookiejar.New(&cookiejar.Options{PublicSuffixList: publicsuffix.List})
 		if err != nil {
 			return nil, err
diff --git a/config/confighttp/client_test.go b/config/confighttp/client_test.go
index ac8cd7593..978a83cb3 100644
--- a/config/confighttp/client_test.go
+++ b/config/confighttp/client_test.go
@@ -32,6 +32,7 @@ import (
 	"go.opentelemetry.io/collector/extension"
 	"go.opentelemetry.io/collector/extension/extensionauth"
 	"go.opentelemetry.io/collector/extension/extensionauth/extensionauthtest"
+	"go.opentelemetry.io/collector/featuregate"
 )

 var (
@@ -75,7 +76,7 @@ func TestAllHTTPClientSettings(t *testing.T) {
 				IdleConnTimeout:      idleConnTimeout,
 				Compression:          "",
 				DisableKeepAlives:    true,
-				Cookies:              CookiesConfig{Enabled: true},
+				Cookies:              configoptional.Some(CookiesConfig{}),
 				HTTP2ReadIdleTimeout: idleConnTimeout,
 				HTTP2PingTimeout:     http2PingTimeout,
 			},
@@ -97,7 +98,7 @@ func TestAllHTTPClientSettings(t *testing.T) {
 				IdleConnTimeout:      idleConnTimeout,
 				Compression:          "",
 				DisableKeepAlives:    true,
-				Cookies:              CookiesConfig{Enabled: true},
+				Cookies:              configoptional.Some(CookiesConfig{}),
 				HTTP2ReadIdleTimeout: idleConnTimeout,
 				HTTP2PingTimeout:     http2PingTimeout,
 			},
@@ -696,6 +697,7 @@ func TestClientUnmarshalYAMLWithMiddlewares(t *testing.T) {
 // TestUnmarshalYAMLComprehensiveConfig tests the complete configuration example
 // to ensure all fields including middlewares are parsed correctly
 func TestClientUnmarshalYAMLComprehensiveConfig(t *testing.T) {
+	require.NoError(t, featuregate.GlobalRegistry().Set("configoptional.AddEnabledField", true))
 	cm, err := confmaptest.LoadConf(filepath.Join("testdata", "config.yaml"))
 	require.NoError(t, err)

Keepalive would need a bit of a rework but is also doable (with some breakage for users, but I expect these options are very rarely used).

The enabled-disabled schism has been discussed today on the Specification SIG meeting (2025-10-28), I am going to try to move that forward a bit more as a pre-requisite for marking this gate as beta.