Expose SentryInstrumentation as bean with @ConditionalOnMissingBean for easy configuration

[ooraini]

Problem Statement

I trying to use SentryInstrumentation.BeforeSpanCallback with the auto configuration from Sentry, but unfortunately with the way it's set up, it's very hard to override. I'm not sure what is the best solution, perhaps it could be defined as @bean with @ConditionalOnMissingBean. I doubt there will be more than one in the application context.

Solution Brainstorm

No response

[adinauer]

Thanks for the suggestion @ooraini we should be able to make it a @Bean with @ConditionalOnMissingBean. As a workaround, can you try to exclude the SentryGraphqlConfiguration and write your own until we change the SDK?

[ooraini]

@adinauer Thanks for the reply

can you try to exclude the SentryGraphqlConfiguration and write your own until we change the SDK?

From what I know(and some research), I don't think you can excluded a @Configuration class, only @AutoConfiguration class can be excluded.

I'll try it out and see, maybe it works.

[jon-mercer]

Adding to this, I just spent entirely too long running down an issue where graphql.execution.instrumentation.Instrumentation beans other than the SentryInstrumentation were not running at all, including spring-graphql's org.springframework.graphql.observation.GraphQlObservationInstrumentation which we were expecting to produce metrics.

Normally what Spring does is find all Instrumentation beans, put them into a single graphql.execution.instrumentation.ChainedInstrumentation and puts that into graphql-java's graphql.GraphQL instance.

I determined the root cause to be that io.sentry.spring.graphql.SentryGraphqlConfiguration is replacing that single ChainedInstrumentation with just SentryInstrumentation, removing all other Instrumentation beans.

If SentryInstrumentation were a @Bean instead of using a GraphQlSourceBuilderCustomizer, this would not be an issue.

So, +1 to the suggestion of making SentryInstrumentation a @Bean instead

[adinauer]

Thanks for the insight @jon-mercer, we'd like to tackle this for the upcoming v8 of the Java SDK.