This reverts commit 0d60a9bc05a4dd792ea69485b30219d1dfef0655 (#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.
This reverts commit 0d60a9bc05a4dd792ea69485b30219d1dfef0655 (#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_timestampforces 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 theSpanInProgressinstance does not have the necessary attributes to calculate it correctly.