[processor/transform] The set function cannot set a field to nil

[TylerHelmuth]

Describe the bug
The Telemetry Query Language has the concept of nil, but the set function doesn't understand it. You cannot do set(attribute["test"], nil). This is because of the nil check in the set function and also because of the setAttr function in each signal's context (traces for example) doesn't know how to handle nil.

The TQL/processor need updated to better support setting nil.

[evan-bradley]

Could this be assigned to me?

[TylerHelmuth]

@evan-bradley its yours.

One thing to think about is that the current implementation allows set(attributes["test"], resource.attributes["test"]) to not update attributes["test"] if resource.attributes["test"] does not exist. This saves the need for a where clause but is kind of an obscure outcome.

To do this change you'll probably have to change the set function so that the above scenario sets attributes["test"] to nil if resource.attributes["test"] does not exist. Do have the same outcome as before users will need to use a where clause: set(attributes["test"], resource.attributes["test"]) where resource.attributes["test"] != nil

I think overall thats an improvement for the language, but should be properly documented as this can be seen as a breaking change for the set function.

[evan-bradley]

Looking for some guidance here: the specification for attributes says that it is undefined behavior to set an attribute value to null, and most language SDKs implement it as a no-op, similar to how the set function currently works. I don't see any obvious fields accessible to the transform processor where nil would be a valid value. How do we want to proceed?

[TylerHelmuth]

Good find. For attributes then it should continue to do nothing.

It does bring up the question of whether or not issue is really valid. Should we let users set anything to nil ? I can't really think of a field in traces, metrics, or logs, where nil is a valid value.

We might be able to close this issue without doing anything.

[evan-bradley]

I agree, I don't think there are any code changes necessary. One follow-up could be to document the motivation for this behavior.

[TylerHelmuth]

Ya good idea. Can you update the set function entry to explain setting anything to nil is no-op