Skip to content

Conversation

@fatihergin
Copy link
Contributor

@fatihergin fatihergin commented Dec 22, 2021

📜 Description

Allows to set startTimestamp(while creating) and endTimestamp(while finishing) manually to SentrySpan

💡 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 yet

  • It 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

  • I reviewed submitted code
  • I added tests to verify changes
  • I updated the docs if needed
  • All tests passing
  • No breaking changes

🔮 Next steps

@fatihergin fatihergin changed the title Allow to set startTimestamp explicitly for SentrySpan Allow to set startTimestamp & endTimestamp manually to SentrySpan Dec 22, 2021
@fatihergin fatihergin force-pushed the feat/allow-to-set-sentryspan-starttimestamp-explicitly branch from 693476e to 651c5f6 Compare December 22, 2021 21:49
@vaind
Copy link
Contributor

vaind commented Jan 3, 2022

Any thoughts/issues with this @marandaneto? We need this (as a sentry.io Business subscriber, if that makes any difference here :)

@codecov-commenter
Copy link

codecov-commenter commented Jan 3, 2022

Codecov Report

Merging #676 (651c5f6) into main (14203b9) will increase coverage by 5.50%.
The diff coverage is n/a.

Impacted file tree graph

@@            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     
Impacted Files Coverage Δ
dart/lib/src/hub.dart
dart/lib/src/hub_adapter.dart
dart/lib/src/noop_hub.dart
dart/lib/src/noop_sentry_span.dart
dart/lib/src/protocol/sentry_span.dart
dart/lib/src/sentry.dart
dart/lib/src/sentry_tracer.dart
dart/lib/src/diagnostic_logger.dart
dart/lib/src/protocol/sentry_culture.dart
dart/lib/src/sentry_client.dart
... and 84 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 14203b9...651c5f6. Read the comment docs.

@fatihergin fatihergin force-pushed the feat/allow-to-set-sentryspan-starttimestamp-explicitly branch 4 times, most recently from 00b1b87 to d0b0db3 Compare February 7, 2022 13:07
Comment on lines 51 to 55
_hub.options.logger(
SentryLevel.warning,
'End timestamp ($endTimestamp) cannot be before start timestamp ($_startTimestamp)',
);
_endTimestamp = getUtcDateTime();
Copy link
Contributor

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.

Copy link
Contributor Author

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;
      });

Copy link
Contributor

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.

Copy link
Contributor Author

@fatihergin fatihergin Mar 7, 2022

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:

  1. in Hub.captureTransaction, before item.client.captureTransaction(transaction): can't modify transaction
  2. in SentryTracer.finish, before _hub.captureTransaction(transaction): can't modify transaction
  3. in constructor of SentryTransaction, while initializing spans: spans = _tracer.children.where(...):
    #(3) might work, but smells. Any recommendation?

Copy link
Contributor

@marandaneto marandaneto Mar 8, 2022

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.

@marandaneto
Copy link
Contributor

Any thoughts/issues with this @marandaneto? We need this (as a sentry.io Business subscriber, if that makes any difference here :)

Sorry late reply, I was on vacay back then and missed the comment.

@marandaneto
Copy link
Contributor

@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. Hub.

@marandaneto
Copy link
Contributor

@brustolin would you mind having a look at it?

@fatihergin
Copy link
Contributor Author

@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. Hub.

I think I did it for hub, hub_adapter, noop_hub and hub_test. It looks there is no other relation between SentrySpan's start & end timestamps and the other packages @marandaneto

@marandaneto
Copy link
Contributor

@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. Hub.

I think I did it for hub, hub_adapter, noop_hub and hub_test. It looks there is no other relation between SentrySpan's start & end timestamps and the other packages @marandaneto

There are untouched packages by this PR, e.g. dio and logging
Those also have mocks of the Hub class and that's why it fails.
See the CI Checks for reference.

@ueman
Copy link
Collaborator

ueman commented Feb 7, 2022

@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. Hub.

I think I did it for hub, hub_adapter, noop_hub and hub_test. It looks there is no other relation between SentrySpan's start & end timestamps and the other packages @marandaneto

There are untouched packages by this PR, e.g. dio and logging Those also have mocks of the Hub class and that's why it fails. See the CI Checks for reference.

That makes me wonder if those mocks should only override what's important to them and then just override noSuchMethod in order to ignore all other methods.

@marandaneto
Copy link
Contributor

@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. Hub.

I think I did it for hub, hub_adapter, noop_hub and hub_test. It looks there is no other relation between SentrySpan's start & end timestamps and the other packages @marandaneto

There are untouched packages by this PR, e.g. dio and logging Those also have mocks of the Hub class and that's why it fails. See the CI Checks for reference.

That makes me wonder if those mocks should only override what's important to them and then just override noSuchMethod in order to ignore all other methods.

yep, that makes a lot of sense.

@marandaneto
Copy link
Contributor

Quick update getsentry/develop#508
Our docs now mention that passing a custom endTimestamp is fine, so we can move forward with this PR.
@fatihergin would you like to address the comments? thanks.

@fatihergin fatihergin force-pushed the feat/allow-to-set-sentryspan-starttimestamp-explicitly branch from d0b0db3 to bce00c3 Compare March 6, 2022 23:41
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)
Copy link
Contributor

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

@marandaneto
Copy link
Contributor

@fatihergin only missing #676 (comment) and fix the changelog entry, otherwise LGTM.

@fatihergin fatihergin force-pushed the feat/allow-to-set-sentryspan-starttimestamp-explicitly branch from bce00c3 to dc1422a Compare March 8, 2022 13:36
@fatihergin fatihergin force-pushed the feat/allow-to-set-sentryspan-starttimestamp-explicitly branch from dc1422a to 2b2fd7d Compare March 8, 2022 18:28
@marandaneto marandaneto merged commit 7bc6840 into getsentry:main Mar 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Archived in project

Development

Successfully merging this pull request may close these issues.

7 participants