-
Notifications
You must be signed in to change notification settings - Fork 0
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
feat: otel updates for latest spec doc #5
Conversation
src/telemetry-tracing.ts
Outdated
} | ||
if (message.orderingKey) { | ||
spanAttributes['messaging.gcp_pubsub.message.ordering_key'] = | ||
spanAttributes['messaging.gcp_pubsub.ordering_key'] = |
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.
Actually the original was right: https://opentelemetry.io/docs/specs/semconv/messaging/gcp-pubsub/
Fixed in the doc
src/publisher/pubsub-message.ts
Outdated
@@ -55,6 +55,23 @@ export interface PubsubMessage | |||
* @private | |||
*/ | |||
publishSchedulerSpan?: tracing.Span; | |||
|
|||
/** | |||
* If this is a message being received from a subscription, expose the ackId. |
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.
I think expose here just means expose to the other parts of the client library and not users right?
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.
Yep. I need to make a whole separate pass of converting @private
to @internal
since tsdoc changed that.
@@ -111,6 +111,7 @@ export abstract class MessageQueue extends EventEmitter { | |||
} | |||
spanMessages.forEach(m => { | |||
tracing.PubsubSpans.updatePublisherTopicName(m.parentSpan!, topic.name); |
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.
Technically not part of this PR but why is this necessary? It looks like the same information is already passed when createPublisherSpan
is called.
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.
Mentioned over chat, but the trouble is that, since everything is async, it's possible that the code could get to the part that sets the initial span name before the project ID is resolved. In that case, the project ID will become {{project}}
in the final span, which isn't great. The project ID must be resolved by this point, so this just makes sure the right names are in place.
Merging this into the upstream PR branch. |
Creating this for easier review on the final spec updates.