remove trace.UpdateName from the spec, or remove warnings against using it

[toumorokoshi]

Hi,

I'd like to propose that the specification make a clear decision about UpdateName, rather than introduce the API, but discourage it's use. The current specification reads:

#### UpdateName

Updates the `Span` name. Upon this update, any sampling behavior based on `Span`
name will depend on the implementation.

It is highly discouraged to update the name of a `Span` after its creation.
`Span` name is often used to group, filter and identify the logical groups of
spans. And often, filtering logic will be implemented before the `Span` creation
for performance reasons. Thus the name update may interfere with this logic.

The function name is called `UpdateName` to differentiate this function from the
regular property setter. It emphasizes that this operation signifies a major
change for a `Span` and may lead to re-calculation of sampling or filtering
decisions made previously depending on the implementation.

Alternatives for the name update may be late `Span` creation, when Span is
started with the explicit timestamp from the past at the moment where the final
`Span` name is known, or reporting a `Span` with the desired name as a child
`Span`.

The section is clear in terms of the reasoning, but practically it's common for consumers to not read the full specification or documentation. As such, one should expect that UpdateName use will not be uncommon, and as such those who process spans cannot rely on the span name being immutable. At that point, all consumers of spans should assume that the span name can be modified, and update their code accordingly. If all consumers handle that case, there's not much value in discouraging the use the API.

I think it would be more helpful for span publishers and consumers to make a decision in one direction or the other:

1. remove UpdateName from the API and specify that the span name is immutable, allowing consumers to write code without handling the update case.
2. remove the "discouraged" warning from the API, making it clear to span consumers that their code should handle span name changes.

[SergeyKanzhelev]

Removing update from API would make semantically clear implementation impossible, at least for C#. It will force create an extra span and do more tricks on span "End".

I'd vote for improving and clarifying the implementation. Now sure if we want to make it before 1.0 though.

[SergeyKanzhelev]

I assigned the milestone "Future" for now.

[toumorokoshi]

Removing update from API would make semantically clear implementation impossible, at least for C#. It will force create an extra span and do more tricks on span "End".

I'd vote for improving and clarifying the implementation. Now sure if we want to make it before 1.0 though.

Got it, good to know. Is there some code that would help me better understand that? (out of curiosity primarily). I also see some issues with losing the API on the Python side.

If that's the case, are there any arguments for discouraging UpdateName use? It seems like consumers would have to handle the UpdateName case.

[SergeyKanzhelev]

Got it, good to know. Is there some code that would help me better understand that? (out of curiosity primarily). I also see some issues with losing the API on the Python side.

ASP.NET gives three events (oversimplifying) - Start, NameResolved (optional), End. NameResolved is optional and you cannot know in advance whether it will be raised at all. Without UpdateName - implementation will need to create a child span on NameResolved event. And indicate to End event to finish both spans. Consumption experience will also be very strange.

We decided for now to now re-apply sampling. If sampling by span name is needed - it must be implemented as post processor or with some custom logic that will parse url in Start callback.

The decision above is not straightforward and will definitely cause issues for advanced users. So the note might help. And we don't want this pattern to be used more widely than required.

[toumorokoshi]

Yes, that makes sense. That's similar to some of the reasoning on the python side too (the actual request starts before the http route is resolved).

We decided for now to now re-apply sampling. If sampling by span name is needed - it must be implemented as post processor or with some custom logic that will parse url in Start callback.

The decision above is not straightforward and will definitely cause issues for advanced users. So the note might help. And we don't want this pattern to be used more widely than required.

I think it makes more sense to remove the note about discouraging UpdateName, and instead just add more information in the sampling section about span name not being a reliable value to sample on.

The existence of the UpdateName API means that, no matter what, SDK authors would have to assume that some consumer will update their name at some point, and act accordingly. As such I'd argue it's more of a consumer of span concern (SDK, processor, sampler) rather than an span producer concern (API).

[jmacd]

I would prefer if we called this SetName and I am happy with removing any warnings about it.

I see the semantics of the Sampler API with respect to SetName as a different conversation, fwiw.

[toumorokoshi]

yeah, I see that point. SetName seems fine to me too.

I'm going to start a PR to at least remove warnings and include this as a caveat in the sampler side.