Skip to content
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

Pass timestamp on OpenTelemetry span close #1064

Merged
merged 1 commit into from
Jun 14, 2024

Conversation

unflxw
Copy link
Contributor

@unflxw unflxw commented Jun 14, 2024

When the SpanProcessor closes a span, before this commit, it would call span.close(), which would call the appsignal_close_span function in the extension, which would override the end time passed as an argument when calling createOpenTelemetrySpan.

To fix this, pass the end time provided by OpenTelemetry again to span.close() when closing the span, re-wiring it so that, if a timestamp is passed, it calls appsignal_close_span_with_timestamp instead. This function already existed in the extension, but a NAPI bridge for it needed to be created.

When the SpanProcessor closes a span, before this commit, it would
call `span.close()`, which would call the `appsignal_close_span`
function in the extension, which would override the end time passed
as an argument when calling `createOpenTelemetrySpan`.

To fix this, pass the end time provided by OpenTelemetry _again_ to
`span.close()` when closing the span, re-wiring it so that, if a
timestamp is passed, it calls `appsignal_close_span_with_timestamp`
instead. This function already existed in the extension, but a NAPI
bridge for it needed to be created.
@unflxw unflxw added the bug label Jun 14, 2024
@unflxw unflxw self-assigned this Jun 14, 2024
@luismiramirez
Copy link
Member

@unflxw
Copy link
Contributor Author

unflxw commented Jun 14, 2024

@luismiramirez Thank you! :)

@unflxw unflxw merged commit 70295aa into main Jun 14, 2024
1 check passed
unflxw added a commit that referenced this pull request Jul 4, 2024
This reverts commit 0d60a9b (#1064)

This did not fix the issue for the customer that I thought it would.
Furthermore, I think my whole mental model of how the spans were
being closed and the timestamps being set was wrong.

Either way, turns out `appsignal_close_span_with_timestamp` forces a
recalculation of the span digest, which is something we don't want to
do, as the span digest is calculated differently, from the
OpenTelemetry extractor output, and the `SpanInProgress` instance
does not have the necessary attributes to calculate it correctly.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants