Problem or motivation
Split out of the #187 review, as agreed there. This is a design question rather than a feature — filing under this template because blank issues are disabled; relabel as needed.
It is downstream of #169 rather than a duplicate: #169 asks whether the internal model should be the OTLP model at all, this asks what the current flattening does with a container value in the meantime. If #169 lands as described, this question disappears with it — which is itself an argument for not over-engineering the answer here.
"What happens to an arbitrary container attribute" has never actually been decided. Before #187 the two paths disagreed, and both behaviours were accidents rather than choices:
# extraction.py, pre-#187 — containers dropped entirely
if "stringValue" ... elif "intValue" ... elif "doubleValue" ... elif "boolValue" ...
return result
# loader/otlp.py, pre-#187 — containers JSON-dumped as raw proto
elif "arrayValue" in value_obj:
result[key] = json.dumps(value_obj["arrayValue"])#187 picks the first one for every unlisted key, purely so the PR changes no behaviour, and defers the real decision here.
Proposed solution
Pick one deliberately. The options as I see them:
|
Behaviour |
Cost |
| Drop (today, post-#187) |
Value disappears, warning logged |
Silent data loss for legitimate array attributes like process.command_args |
| JSON-dump the decoded value |
["stop"] rather than {"values":[{"stringValue":"stop"}]} |
Consumers that expected absence now get a string; changes truthiness in if attrs.get(k): branches |
| Keep the container |
Full fidelity |
Any consumer using the value as a dict key or set member raises TypeError, on an unauthenticated receiver port |
Whatever is chosen, SPEC_CONTAINER_ATTRS stays as the set that gets native containers; this is only about the default for everything else.
Happy to implement whichever direction you pick.
Alternatives considered
Leaving it as-is (drop) indefinitely. That is defensible while #169 is open, but it is currently an accident inherited from extraction.py rather than a 1decision, and nothing in the code says so.
Additional context
resource_attrs flows into session.metadata and then to the UI, so this is user-visible rather than purely internal. Standard resource semconv has array-typed attributes we hold no constants for — process.command_args is one. Under "drop" they stay invisible; under "JSON-dump" they would start appearing in session metadata.
Human confirmation
Problem or motivation
Split out of the #187 review, as agreed there. This is a design question rather than a feature — filing under this template because blank issues are disabled; relabel as needed.
It is downstream of #169 rather than a duplicate: #169 asks whether the internal model should be the OTLP model at all, this asks what the current flattening does with a container value in the meantime. If #169 lands as described, this question disappears with it — which is itself an argument for not over-engineering the answer here.
"What happens to an arbitrary container attribute" has never actually been decided. Before #187 the two paths disagreed, and both behaviours were accidents rather than choices:
#187 picks the first one for every unlisted key, purely so the PR changes no behaviour, and defers the real decision here.
Proposed solution
Pick one deliberately. The options as I see them:
process.command_args["stop"]rather than{"values":[{"stringValue":"stop"}]}if attrs.get(k):branchesTypeError, on an unauthenticated receiver portWhatever is chosen,
SPEC_CONTAINER_ATTRSstays as the set that gets native containers; this is only about the default for everything else.Happy to implement whichever direction you pick.
Alternatives considered
Leaving it as-is (drop) indefinitely. That is defensible while #169 is open, but it is currently an accident inherited from extraction.py rather than a 1decision, and nothing in the code says so.
Additional context
resource_attrs flows into session.metadata and then to the UI, so this is user-visible rather than purely internal. Standard resource semconv has array-typed attributes we hold no constants for — process.command_args is one. Under "drop" they stay invisible; under "JSON-dump" they would start appearing in session metadata.
Human confirmation