-
Notifications
You must be signed in to change notification settings - Fork 845
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(api-logs): align AnyValue to spec #4893
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||
---|---|---|---|---|
|
@@ -14,16 +14,29 @@ | |||
* limitations under the License. | ||||
*/ | ||||
|
||||
import { AttributeValue } from '@opentelemetry/api'; | ||||
export type AnyValueScalar = string | number | boolean; | ||||
|
||||
export type AnyValueArray = Array<AnyValue>; | ||||
|
||||
/** | ||||
* AnyValueMap is a map from string to AnyValue (attribute value or a nested map) | ||||
*/ | ||||
export interface AnyValueMap { | ||||
[attributeKey: string]: AnyValue | undefined; | ||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. reviewer note: since now |
||||
[attributeKey: string]: AnyValue; | ||||
} | ||||
|
||||
/** | ||||
* AnyValue is a either an attribute value or a map of AnyValue(s) | ||||
* AnyValue can be one of the following: | ||||
* - a scalar value | ||||
* - a byte array | ||||
* - array of any value | ||||
* - map from string to any value | ||||
* - empty value | ||||
*/ | ||||
export type AnyValue = AttributeValue | AnyValueMap; | ||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. reviewer note: Since
Then removing it and adding the |
||||
export type AnyValue = | ||||
| AnyValueScalar | ||||
| Uint8Array | ||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There are several typed array types, do we want to have them all listed here? https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/TypedArray Maybe having a AnyTypedArray type now There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think any of the other TypedArrays would get borked on OTLP export. The
But doesn't know the other TypeArrays. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I followed what the spec wording that said Since byte is 0-255, I think it aligns with Uint8 in contrast to However, it will still be exported (to my understanding) as if (Array.isArray(value))
return { arrayValue: { values: value.map(toAnyValue) } }; There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think it will be exported as an object with integer-string keys, because:
From my playing around on open-telemetry/opentelemetry-js-contrib#2352 (comment) and with a LogRecord with an attribute
FWIW, this is basically how
|
||||
| AnyValueArray | ||||
| AnyValueMap | ||||
| null | ||||
| undefined; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should support bigint here as well
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://opentelemetry.io/docs/specs/otel/logs/data-model/#type-any says:
but JS's
MAX_SAFE_INTEGER
is less than that...so, probably, yes we should add BigInt?
However BigInt requires Node.js 10.4.0 and api/package.json (the package in which api-logs eventually will land) has:
so, I'm not sure if that is a problem.
There was some discussion around BigInt usage in some exporters-related PR a while back I thought.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
However, this could be discussed separate from this PR. This change isn't removing BigInt from the type.