Open nikolaianohyn opened 2 years ago
Hey @nikolaianohyn thanks for raising this issue!
Unfortunately I don't believe this is something the team wants to add, we already mention clearly in the documentation that environment variables take precedence over anything else:
Environment variables take precedence over Config values, which take precedence over any default value.
So it would be a big change to alter that behavior. Hopefully you have enough solutions to make it work for your needs? Otherwise please describe your use case more in depth and we'll try to help you with it 🙂
@NathanielRN In my opinion values from code must be in priority compared to environments. I already have service name in trace. I don't want segments with the same name. It looks useless.
You have code:
You use it for GRPC interceptor, but instead of MethodName I got serviceName twice.
Hey @nikolaianohyn, thanks for explaining further. I brought this up with the team and we can see that it is consistent across other SDKs. This is probably because 1 segment == 1 service usually. So the use of the name for the service in the trace would make sense.
Are you able to make a subsegment
to wrap your method and get the name you are looking for? Can this be a workaround for you?
@NathanielRN I see the problems in the logic and code. In GRPC interceptor you call NewSegmentFromHeader with MethodName argument. So I expect to see in UI this MethodName. Instead of this I can't understand which grpc method was called. I see only service, but my service has a lot of endpoints.
According the code bellow I can't redefine name of trace if I set up AWS_XRAY_TRACING_NAME env. I think we should add in this condition:
&& name == ""