Skip to content
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

[instrumentation/google.golang.org/grpc/otelgrpc] Do not assume HandleRPC receives a gRPCContext #4825

Merged
merged 8 commits into from
Jan 18, 2024

Conversation

mx-psi
Copy link
Member

@mx-psi mx-psi commented Jan 17, 2024

Copy link

codecov bot commented Jan 17, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (a28c68b) 81.3% compared to head (9be483c) 81.3%.

Additional details and impacted files

Impacted file tree graph

@@          Coverage Diff          @@
##            main   #4825   +/-   ##
=====================================
  Coverage   81.3%   81.3%           
=====================================
  Files        150     150           
  Lines      10885   10890    +5     
=====================================
+ Hits        8853    8858    +5     
  Misses      1873    1873           
  Partials     159     159           
Files Coverage Δ
...n/google.golang.org/grpc/otelgrpc/stats_handler.go 100.0% <100.0%> (ø)

@mx-psi mx-psi changed the title [instrumentation/google.golang.org/grpc/otelgrpc] Add safeguard to HandleRPC [instrumentation/google.golang.org/grpc/otelgrpc] Do not assume HandleRPC receives a gRPCContext Jan 17, 2024
@mx-psi mx-psi requested a review from Aneurysm9 January 17, 2024 18:28
@pellared
Copy link
Member

pellared commented Jan 17, 2024

Is it not an effect of bug in https://github.com/grpc/grpc-go? If so could you additionally report it there?

References:

It would be also great to reproduce the issue and have a test that would help avoiding regression bugs.

Side note: I am not against having a "defensive" code.

gctx, ok := ctx.Value(gRPCContextKey{}).(*gRPCContext)
if ok && gctx != nil {
metricAttrs = make([]attribute.KeyValue, 0, len(gctx.metricAttrs)+1)
metricAttrs = append(metricAttrs, gctx.metricAttrs...)
Copy link

Choose a reason for hiding this comment

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

You can use copy instead of you replace the zero on the preceding line with the length of the source slice. Alternately, consider using the slices.Clone function if you don't really need that extra slot in the backing array. It's implemented by append today, without the preceding call to make.

Copy link
Member Author

Choose a reason for hiding this comment

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

Since this was already there and I am only moving it inside the if block, I would prefer to do this change on a separate PR if that's okay

@codeboten
Copy link
Contributor

Is it not an effect of bug in https://github.com/grpc/grpc-go? If so could you additionally report it there?

References:

* https://github.com/grpc/grpc-go/tree/master/examples/features/stats_monitoring

* https://pkg.go.dev/google.golang.org/grpc/stats#Handler

It would be also great to reproduce the issue and have a test that would help avoiding regression bugs.

Side note: I am not against having a "defensive" code.

It's not clear to me why this was not encountered before, but the examples in the grpc repo does suggest that defensive code is the way to go here: https://github.com/grpc/grpc-go/blob/ddd377f19841eae70862559c854d957d61b3b692/examples/features/stats_monitoring/statshandler/handler.go#L73

I'm not sure if this expected behaviour or a new behaviour though.

@pellared
Copy link
Member

pellared commented Jan 17, 2024

It's not clear to me why this was not encountered before, but the examples in the grpc repo does suggest that defensive code is the way to go here

I agree. Therefore, I am not against the change here.

Still, the docs suggests that it should not happen.
I think it might be worth reporting a bug. However, we should have repro steps...

Copy link
Member

@pellared pellared left a comment

Choose a reason for hiding this comment

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

@MadVikingGod IMO we can consider adding it to the upcoming release.

@mx-psi Can you please still follow-up and try to reproduce it and eventually create an issue in https://github.com/grpc/grpc-go?

@mx-psi
Copy link
Member Author

mx-psi commented Jan 18, 2024

Filed grpc/grpc-go/issues/6928. I still don't have a way to reproduce the issue, but I at least shared all we know so far. Feel free to comment if anything is missing there.

@MadVikingGod MadVikingGod merged commit 40290ea into open-telemetry:main Jan 18, 2024
22 checks passed
@pellared pellared added this to the untracked milestone Nov 8, 2024
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.

7 participants