-
-
Notifications
You must be signed in to change notification settings - Fork 451
Add thread information when a span is created #2998
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
Merged
Merged
Changes from all commits
Commits
Show all changes
7 commits
Select commit
Hold shift + click to select a range
1e73b22
Tag all spans with main thread flag
markushi 83f7838
Update Changelog
markushi ea3057a
Merge branch 'main' into feat/starfish-span-mainthread-flag
markushi fb44d20
Attach thread.id and thread.name to spans
markushi f2ba64f
Fix tests
markushi 28c4130
Merge branch 'main' into feat/starfish-span-mainthread-flag
markushi ce0469b
Fix Changelog
markushi File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -5,6 +5,7 @@ import io.sentry.hints.Retryable | |
import io.sentry.protocol.SentryId | ||
import io.sentry.protocol.SentryTransaction | ||
import io.sentry.util.HintUtils | ||
import io.sentry.util.thread.NoOpMainThreadChecker | ||
import org.mockito.kotlin.any | ||
import org.mockito.kotlin.argWhere | ||
import org.mockito.kotlin.check | ||
|
@@ -38,6 +39,7 @@ class OutboxSenderTest { | |
init { | ||
whenever(options.dsn).thenReturn("https://[email protected]/proj") | ||
whenever(options.dateProvider).thenReturn(SentryNanotimeDateProvider()) | ||
whenever(options.mainThreadChecker).thenReturn(NoOpMainThreadChecker.getInstance()) | ||
whenever(hub.options).thenReturn(this.options) | ||
} | ||
|
||
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Did we agree to use the same
blocked_main_thread
key? I'd rather us choose something different, because we don't know for sure if it blocked the main thread, we know that it was just started there? Also, if we pick a different key, the current behavior for File I/O or DB spans will remain the same withblocked_main_thread
.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.
Nope, this wasn't discussed yet - thanks for bringing this up. @shruthilayaj I think Roman has some good points here, would it make sense for you as well to have a separate flag for main thread flagging?
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, it makes sense to have these as separate flags!
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.
A bit lengthy, but how about
started_on_main_thread
? Would also make it clear that the flag is determined on span start.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 rfc https://github.com/getsentry/rfcs/pull/75/files got merged just a couple of days ago, so we probably should adhere to what is defined there. Here's the develop docs PR which adds the the new keys to the span data conventions getsentry/develop#1056, which means we have to send
thread.id
andthread.name
, how does that sounds @shruthilayaj @markushi ?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.
h
: I just wanted to make the same comment ⬆️ . Thanks @romtsn.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.
👍
just to confirm, sending
thread.id
andthread.name
in addition tostarted_on_main_thread
flag 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.
mm, since in the RFC we say it's the thread the span originated from, I think

thread.name: main
would be the same thing pretty much, so we don't need both flags?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.
yeah makes sense, and will thread name always be standardized to
main
if it started on the main thread regardless of the SDK it's coming from? (just so we know if we just look formain
or need to maintain some sort of map/allow list for extracting this info in relay)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'd start with just
main
, I guess we can expand it later. We can ensure that it's calledmain
from the SDKs side