[cmd/mdatagen] `generated_component_test.go` should handle expected factory failures

[braydonk]

Component(s)

cmd/mdatagen

Describe the issue you're reporting

There are some scenarios, such as platform support, where a component factory is expected to fail. The component test template always assumes that the factory is going to succeed, meaning on unsupported platforms the test will fail.

Perhaps a template could be added to mdatagen that will generate another component_test.go under different build tags that expects the factory to error out?

Alternatives

Perhaps we think factories should never error out and simply fail every scrape with an unsupported platform error? I would think we should prefer failing fast at the configuration stage for something like this though.

EDIT: Discussion in the Collector SIG on May 21, 2025 leaned almost unanimously in favour of factories failing fast.

[github-actions]

Pinging code owners:

• cmd/mdatagen: @dmitryax

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[sincejune]

I looked at some modules in the contrib repo and noticed that we've used files like factory_windows.go to handle platform-specific issues (though I'm not sure if this is good enough with your use case).

Adding some failure checks sounds reasonable, but addressing the platform issue here feels unnecessarily complex. @braydonk What do you think? cc @dmitryax

[braydonk]

we've used files like factory_windows.go to handle platform-specific issues

I've done this too in some components we manage in our own repos: https://github.com/GoogleCloudPlatform/opentelemetry-operations-collector/blob/master/components/otelopscol/receiver/nvmlreceiver/factory_gpu_off.go

The issue of the generated lifecycle tests failing under the !gpu build tag was still a problem. Since this is our component we manage in our repo, we just make a point of deleting generated_component_test.go as part of our mdatagen process. (We've had this issue for ages but I've been ignoring it because we just delete the file, now that it's something in contrib we don't have that option lol)

[jmacd]

I have been tempted to skip a lifecycle test, and this is a similar problem--let me explain.

The OTel-Arrow exporter has in the past given recommendations on batching, and as I wanted to update the exporter to use the new combined queue/batch support, I ran into a test failure in the lifecycle test. The test starts a component (exporter) without starting a corresponding receiver, then sends a request with no deadline.

					err = e.ConsumeTraces(context.Background(), traces)

Why would we expect success, then, which the test aims to verify? Because the default behavior of using the queue has always meant that one request is permitted to enter, the test will pass quickly. Shutdown in this test exercises the case of a request stuck in the queue for typical components.

I had considered to change the OTel-Arrow exporter default to set WaitForResult: true which would emulate the concurrentbatchprocessor component that we had built. This setting, however, causes the lifecycle test to fail after waiting the default retry max-elapsed periods, so a 5m test failure.

I would expect (a) the lifecycle test to use a context timeout of something more reasonable. I would expect it to be possible to set WaitForResult: true by default and still pass a lifecycle test--however the test should expect failure in that case (after the appropriate timeout).

[braydonk]

Turns out there was more available to control this than I thought:

status::unsupported_platforms are used to generate build constraints for generated_component_test.go which essentially covers the original purpose of this issue:

opentelemetry-collector/cmd/mdatagen/internal/templates/component_test.go.tmpl

Line 3 in 4a37179

{{- if len .Status.UnsupportedPlatforms }}

tests::skip_lifecycle and tests::skip_shutdown will control whether the lifecycle or shutdown tests are run:

opentelemetry-collector/cmd/mdatagen/internal/templates/component_test.go.tmpl

Line 10 in 4a37179

{{- if not (and .Tests.SkipLifecycle .Tests.SkipShutdown) }}

So I think my own problems are covered, at least the original purpose of my issue is resolved so I will close this issue. But what @jmacd mentioned in his comments is valid too, maybe should be moved into its own issue.