You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was trying to setup observability for application, that use both GrpcServer and GrpcClient.
The bug
It seems that configuration order of micrometer tracing breaks when I add @GrpcClient like ctor parameter for my service, for example:
@Service
class MyService(
@GrpcClient("my-client")
private val myClient: OtherServiceGrpcKt.OtherServiceCoroutineStub
) {...}
The ObservationRegistry, needed to configure tracing interceptors is noOp, so traces don't work.
Everything works fine if I add @GrpcClient as lateinit property to my service and do not use ctor injection.
Also works if I add Configuration with @GrpcClientBean and inject client beans without @GrpcClient. (btw, it seems that @dependsOn on config with client beans is necessary, otherwise spring fails to find these beans)
And also (that is strange) works if I exclude GrpcClientMicrometerAutoConfiguration:
and copy-paste source code of this class to my own code)
Stacktrace and logs
There are tons of WARNs like: trationDelegate$BeanPostProcessorChecker : Bean 'net.devh.boot.grpc.client.autoconfigure.GrpcClientAutoConfiguration' of type [net.devh.boot.grpc.client.autoconfigure.GrpcClientAutoConfiguration] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying). Is this bean getting eagerly injected into a currently created BeanPostProcessor [grpcClientBeanPostProcessor]? Check the corresponding BeanPostProcessor declaration and its dependencies.
These WARNs are absent in 2) and 3).
Steps to Reproduce
Steps to reproduce the behavior:
Create class via the @GrpcClient injected in ctor.
Expose some endpoint like hello and try to log traceIds there
(*) Try to add logging via ObservationHandler and see that your handler is not registered (and ObservationRegistry is noop as well).
The application's environment
Which versions do you use?
Spring (boot): 3.3.0
grpc-java: 1.64.0
grpc-kotlin-stub: 1.4.1
grpc-spring-boot-starter: 3.1.0.RELEASE
Additional context
I see that @GrpcClient constructor injection is experimental (as said in javadoc). Hope this issue helps you somehow
The text was updated successfully, but these errors were encountered:
The context
I was trying to setup observability for application, that use both GrpcServer and GrpcClient.
The bug
It seems that configuration order of micrometer tracing breaks when I add @GrpcClient like ctor parameter for my service, for example:
The
ObservationRegistry
, needed to configure tracing interceptors isnoOp
, so traces don't work.Everything works fine if I add
@GrpcClient
aslateinit property
to my service and do not use ctor injection.Also works if I add
Configuration
with@GrpcClientBean
and inject client beans without @GrpcClient. (btw, it seems that @dependsOn on config with client beans is necessary, otherwise spring fails to find these beans)And also (that is strange) works if I exclude
GrpcClientMicrometerAutoConfiguration
:and copy-paste source code of this class to my own code)
Stacktrace and logs
There are tons of WARNs like:
trationDelegate$BeanPostProcessorChecker : Bean 'net.devh.boot.grpc.client.autoconfigure.GrpcClientAutoConfiguration' of type [net.devh.boot.grpc.client.autoconfigure.GrpcClientAutoConfiguration] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying). Is this bean getting eagerly injected into a currently created BeanPostProcessor [grpcClientBeanPostProcessor]? Check the corresponding BeanPostProcessor declaration and its dependencies.
These WARNs are absent in 2) and 3).
Steps to Reproduce
Steps to reproduce the behavior:
ObservationHandler
and see that your handler is not registered (and ObservationRegistry is noop as well).The application's environment
Which versions do you use?
Additional context
I see that @GrpcClient constructor injection is experimental (as said in javadoc). Hope this issue helps you somehow
The text was updated successfully, but these errors were encountered: