-
-
Notifications
You must be signed in to change notification settings - Fork 277
Allow to set startTimestamp & endTimestamp manually to SentrySpan #676
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
Allow to set startTimestamp & endTimestamp manually to SentrySpan #676
Conversation
693476e to
651c5f6
Compare
|
Any thoughts/issues with this @marandaneto? We need this (as a sentry.io Business subscriber, if that makes any difference here :) |
Codecov Report
@@ Coverage Diff @@
## main #676 +/- ##
==========================================
+ Coverage 90.65% 96.15% +5.50%
==========================================
Files 97 2 -95
Lines 3145 52 -3093
==========================================
- Hits 2851 50 -2801
+ Misses 294 2 -292 Continue to review full report at Codecov.
|
00b1b87 to
d0b0db3
Compare
| _hub.options.logger( | ||
| SentryLevel.warning, | ||
| 'End timestamp ($endTimestamp) cannot be before start timestamp ($_startTimestamp)', | ||
| ); | ||
| _endTimestamp = getUtcDateTime(); |
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.
This is a good idea, but getUtcDateTime() can still be technically before the given _startTimestamp.
This needs to be tried/tested and see if Sentry.io throws an ingestion error or just an UI warning, otherwise we have to fix on the SDK side.
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.
AFAIU, Sentry JS simply discards spans if end timestamp is before start timestamp.
Should this approach be applicable here?
this.spanRecorder.spans = this.spanRecorder.spans.filter((span: Span) => {
// If we are dealing with the transaction itself, we just return it
if (span.spanId === this.spanId) {
return true;
}
...
const keepSpan = span.startTimestamp < endTimestamp;
if (!keepSpan) {
logger.log(
'[Tracing] discarding Span since it happened after Transaction was finished',
JSON.stringify(span, undefined, 2),
);
}
return keepSpan;
});
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.
Yes, otherwise it'll be discarded in the event ingestion, so no need to send the data over.
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 can't find a suitable place to filter invalid spans out.
Possible places:
- in Hub.captureTransaction, before item.client.captureTransaction(transaction): can't modify transaction
- in SentryTracer.finish, before _hub.captureTransaction(transaction): can't modify transaction
- in constructor of SentryTransaction, while initializing spans: spans = _tracer.children.where(...):
#(3) might work, but smells. Any recommendation?
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.
@fatihergin I believe SentryTracer#finish is the way to go, within the for loop from L67-L73, just remove the child span from the _children list if the timestamp is out of bounds.
Sorry late reply, I was on vacay back then and missed the comment. |
|
@fatihergin since there were changes in the public API, please check the other packages within this repo, they might need to be fixed too, e.g. |
|
@brustolin would you mind having a look at it? |
I think I did it for |
There are untouched packages by this PR, e.g. dio and logging |
That makes me wonder if those mocks should only override what's important to them and then just override |
yep, that makes a lot of sense. |
|
Quick update getsentry/develop#508 |
d0b0db3 to
bce00c3
Compare
CHANGELOG.md
Outdated
|
|
||
| * Fix: Disable log by default in debug mode (#753) | ||
| * [Dio] Ref: Replace FailedRequestAdapter with FailedRequestInterceptor (#728) | ||
| * Feat: Allow to set startTimestamp & endTimestamp manually to SentrySpan (#676) |
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.
This should go under the Unreleased entry
|
@fatihergin only missing #676 (comment) and fix the changelog entry, otherwise LGTM. |
bce00c3 to
dc1422a
Compare
dc1422a to
2b2fd7d
Compare
📜 Description
Allows to set
startTimestamp(while creating) andendTimestamp(while finishing) manually toSentrySpan💡 Motivation and Context
It will allow to trace events which Sentry does not have control over starting point of that events.
e.g. When a 3rd party SDK returns only duration of an internal execution which is wanted to trace.
p.s. It's already implemented (
startTimestamp) on sentry-java with the motivation of tracing app-start time where Sentry not initialized yetIt will give more control over transactions in terms of creating&finishing them.
It might be desired to decide whether to start a transaction or not conditionally which will be clear at a later time after starting the operation.
💚 How did you test it?
Unit tests
📝 Checklist
🔮 Next steps