Move the evaluated value from the event body to attributes #1990
Conversation
| |---|---|---| | ||
| | `boolean` | The `feature_flag.result.value` is a stringified boolean. |  | | ||
| | `number` | The `feature_flag.result.value` is a stringified number. |  | | ||
| | `object` | The `feature_flag.result.value` is a stringified object. |  | |
There was a problem hiding this comment.
An object may be massive. Should we be worried about size or leave that up to the implementor?
There was a problem hiding this comment.
can you mention this in the notes for this attribute? we discussed large attributes in the log/event SIG just yesterday as this is also an issue coming up in GenAI events. we currently want these to (generally) go into event attributes, and are exploring ways to indicate these (potentially) large attributes to pipelines/backends so they can choose alternative storage for them if they want
there's also a case to be made for this to remain in the body if it's going to be large and if it's the central thing reported by the event. e.g. we are still debating whether mobile crash dumps should be reported as an event attribute or event body
There was a problem hiding this comment.
I can add a note. I think it's not expected that it is often large, but it can be. In that case is attribute still appropriate?
There was a problem hiding this comment.
if it's going to be large
I think it's only sometimes large
and if it's the central thing reported by the event
The evaluation result is obviously important, but we expect variant (a short name that identifies a result) to be used more often. Some systems don't have a concept of variant though
| | [`feature_flag.context.id`](/docs/attributes-registry/feature-flag.md) | string | The unique identifier for the flag evaluation context. For example, the targeting key. | `5157782b-2203-4c80-a857-dbbd5e7761db` | `Recommended` |  | | ||
| | [`feature_flag.evaluation.error.message`](/docs/attributes-registry/feature-flag.md) | string | A message explaining the nature of an error occurring during flag evaluation. | `Flag `header-color` expected type `string` but found type `number`` | `Recommended` [5] |  | | ||
| | [`feature_flag.evaluation.error.message`](/docs/attributes-registry/feature-flag.md) | string | A message explaining the nature of an error occurring during flag evaluation. | `Flag `header-color` expected type `string` but found type `number`` | `Recommended` [7] |  | |
There was a problem hiding this comment.
Should the be evaluation or result? It seems odd to me to use result for success and evaluation for failure.
There was a problem hiding this comment.
I think this should be (generic) error.message, which we don't have, but I would support.
It's essentially what we put in span status description on spans, but don't have a place today to put on events.
@lmolkova wdyt?
There was a problem hiding this comment.
I left it as evaluation because in a failure scenario you might not actually have a result. its the evaluation that fails
There was a problem hiding this comment.
Created a PR for discussion about generic error.message #1992
| Because the evaluated flag value is unstructured and may be any type, it left to the instrumentation author to determine how best to achieve this. | ||
| - id: feature_flag.result.type | ||
| type: | ||
| members: |
There was a problem hiding this comment.
I'm currently missing null which is a valid JSON type but is not a valid attribute. @trask what is generally the protocol here? Should I put anything technically representable? Or should I limit to what is allowed in attribute values?
This came as a result of @trask reviewing the feature flag semconv to move away from body fields to attributes.
typeis also added because the evaluated value can be any type.