Split out RpcAttributesGetter #5548
Conversation
There was a problem hiding this comment.
I thought it would be useful to split the extractors into
RpcClientAttributesExtractorandRpcServerAttributesExtractorbecause they will have differentSpanKeys associated to them; there's only one getter interface though, cause both extractors use it to retrieve the same set of attributes.
Do you think it makes sense to proactively split the getter as well (similar to http client/server getter) in case rpc client/server attributes diverge in the future?
I thought about it too and in the end I couldn't decide whether to do it or not -- I'll try it out and push the change here, let's see if it looks manageable. |
@anuraaga thoughts? |
|
I think unlike HTTP RPC has a stronger tendency to have the same data in server / client so we could probably avoid splitting now. |
sounds good, IIRC our current thinking is to not stabilize a semantic attributes extractor until that semantic convention is declared stable, so that gives us some time to see if anything new emerges for rpc |
|
@mateuszrzeszutek heads up conflicts |
mateuszrzeszutek
force-pushed
the
extract-rpc-getter
branch
from
3ce9ca7
to
d648f03
Compare
* Split out RpcAttributesGetter * code review comments * go back to RpcAttributesGetter
Part of #5291
I thought it would be useful to split the extractors into
RpcClientAttributesExtractorandRpcServerAttributesExtractorbecause they will have differentSpanKeys associated to them; there's only one getter interface though, cause both extractors use it to retrieve the same set of attributes.