Skip to content

[receiver/otlpreceiver] Use configoptional type #13119

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

mx-psi
Copy link
Member

@mx-psi mx-psi commented May 30, 2025

Description

Uses configoptional.Optional for fields in protocols section.

Removes Unmarshal method since it is no longer needed.

These are both breaking changes, I think it would be a bit difficult to do this in two steps, I am happy to work on fixing contrib after this is merged.

Link to tracking issue

Fixes #12980

Copy link

codecov bot commented May 30, 2025

Codecov Report

Attention: Patch coverage is 94.11765% with 1 line in your changes missing coverage. Please review.

Project coverage is 91.59%. Comparing base (4a37179) to head (7d99cb7).
Report is 27 commits behind head on main.

Files with missing lines Patch % Lines
receiver/otlpreceiver/otlp.go 92.30% 0 Missing and 1 partial ⚠️

❌ Your patch status has failed because the patch coverage (94.11%) is below the target coverage (95.00%). You can increase the patch coverage or adjust the target coverage.

Additional details and impacted files
@@            Coverage Diff             @@
##             main   #13119      +/-   ##
==========================================
- Coverage   91.60%   91.59%   -0.01%     
==========================================
  Files         506      506              
  Lines       28544    28533      -11     
==========================================
- Hits        26147    26136      -11     
  Misses       1882     1882              
  Partials      515      515              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@mx-psi mx-psi marked this pull request as ready for review May 30, 2025 10:25
@mx-psi mx-psi requested a review from a team as a code owner May 30, 2025 10:25
@mx-psi
Copy link
Member Author

mx-psi commented May 30, 2025

I think this one should not have any controversy (configoptional.Optional was designed for this specific type of optional after all). I also avoided adding the GetOrInsertDefault as part of the public API by just defining it in tests.

Comment on lines +28 to +38
func GetOrInsertDefault[T any](t *testing.T, opt *configoptional.Optional[T]) *T {
if opt.HasValue() {
return opt.Get()
}

empty := confmap.NewFromStringMap(map[string]any{})
require.NoError(t, empty.Unmarshal(opt))
val := opt.Get()
require.NotNil(t, "Expected a default value to be set for %T", val)
return val
}
Copy link
Contributor

@rogercoll rogercoll Jun 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is useful enough to be part of the Optional type API, something like what the mo package provides:

// MapNone executes the mapper function if value is absent or returns Option.
func (o Optional[T]) MapNone(mapper func() (T, bool)) Optional[T] {
	if o.hasValue {
		return Some(o.value)
	}

	return ToOption(mapper())
}

(no need to change this PR)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah originally in one of my PoCs this was a method in Optional itself, but I got feedback that if it was only used in tests we could just not have it as part of configoptional. I think it may make sense to add it to the main API/a test module, but since we don't have to decide that now, I would rather keep it here

Comment on lines +91 to +95
if !r.cfg.GRPC.HasValue() {
return nil
}

grpcCfg := r.cfg.GRPC.Get()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could simplify these cases by extending the Get() to return (T, bool) instead.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Considering Get() returns a *T, I think you could just check whether it's nil.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is a good point. Since that does not change the API substantially I would prefer also doing this in a separate PR. I'll wait to see what others say and file an issue to address this before we mark configoptional 1.0

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about creating another function for pointer return ToPointer and Get returning the value? The return type could be a private empty one return empty[T](), false

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Considering Get() returns a *T, I think you could just check whether it's nil.

I mean, yeah, but that is not the usual Go pattern

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking about this during the PR for adding the configoptional package. I like that HasValue gates the rest of the function and avoids nesting, but I see the value in the other approaches as well.

My thought was that we see how this is used in a few places and see which pattern ends up being the cleanest for the typical case. From what I can tell, outside the reduced API of removing HasValue and checking whether *T is nil or ok is true for (T, bool), none of the options are substantially cleaner than the others.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's continue over at #13160

Copy link
Contributor

@evan-bradley evan-bradley left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the slow review. I like the way this looks.

@mx-psi
Copy link
Member Author

mx-psi commented Jun 5, 2025

I am going to merge this, although I want to make some changes to Unmarshal for Optional when unmarshaling into a None, after discussing with Jade. This will have no impact on the usage on the OTLP receiver, and, in any case, no impact on the end-users so I feel comfortable merging this so that we release it

@mx-psi mx-psi added this pull request to the merge queue Jun 5, 2025
Merged via the queue into open-telemetry:main with commit e8ca607 Jun 5, 2025
61 of 80 checks passed
@mx-psi mx-psi deleted the mx-psi/otlpreciever-configoptional branch June 5, 2025 11:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[receiver/otlp] Use Optional type to define optional configuration fields
4 participants