i wonder if it would make sense to add @Nullable to the parameter in suppressSpan (and all the other downstream effects of that) to avoid having to suppress this?

I tried that - and it's not working (have to look up the details if required)

can you check? I'm asking because the reason "request is typed as Void" doesn't really seem correct here. Rather the reason seems that the method really does accept Nullable.

InstrumenterUtil.suppressSpan() calls spanKindExtractor.extract(request) which doesn't accept a null request. Here it works because the instrumenter uses SpanKindExtractor.alwaysConsumer() that doesn't use the request.
The comment // request is typed as Void is misleading as here request is MessageWithDestination and the response is Void.

thanks @laurit - I really got it wrong and fixed the comment now

this seems like the honest thing to do:

i wonder if it would make sense to add @Nullable to the parameter in suppressSpan (and all the other downstream effects of that) to avoid having to suppress this?

this seems like the honest thing to do:

i wonder if it would make sense to add @Nullable to the parameter in suppressSpan (and all the other downstream effects of that) to avoid having to suppress this?

Then we'd need to make SpanKindExtractor#extract accept nullable. I'm not sure sure it is justified given suppressSpan is an internal method. What if we introduced a second suppressSpan method that accepted span kind instead of the request suppressSpan(Instrumenter<REQUEST, RESPONSE> instrumenter, Context parentContext, SpanKind spanKind) Since we know what the span kind is going to be we can avoid extracting it from the instrumenter.

@laurit that's an elegant solution! Added.