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.
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
feat(nextjs): Create transactions in
getInitialProps
andgetServerSideProps
#5593feat(nextjs): Create transactions in
getInitialProps
andgetServerSideProps
#5593Changes from all commits
f311209
e189fcb
9f4a2b1
848f03f
fe67cdb
4205f31
74edafb
cf22932
afbe522
59bb0d8
29ee43f
dc9988c
a561697
0e0d912
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
This file was deleted.
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.
Hmmm... What happens if multiple data-fetching functions for the same request are running at the same time? (Not a current concern, but it will be one eventually, and I figure we should future-proof ourselves as much as we can.)
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 think we're good in this situation. Since we have an individual domain for each of the data fetchers, they also have their own hub/cloned scope, so setting the span should "just work". Let me know if I misunderstand something.
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, okay, I see what you're saying. I think I'm stuck in the mindset which applies in our other framework integrations, where it's one domain/request. I'm trying to think if there's any reason we'd need to have all of a request's data fetchers live in the same domain. I guess the question is, is there anything which happens to the scope in one which we'd want to be persisted to another?
Thoughts:
So I think the answer is no, because we don't know the order in which they'll run, so even if they were in the same domain, we couldn't count on one setting data that the next one could use. The one exception here is the event processor to add request data. That's gotta be attached to whatever scope is active when we call
transaction.finish
. Off-the-cuff idea: In addition to attaching the transaction to the request, we should also store a reference to the request in the transaction metadata. Then we can add an event processor at SDK startup which grabs the request out ofsdkProcessingMetadata
and uses it to populate request data into the event.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 spent the night thinking about if there is a really good reason for only having one domain across all data fetchers, since having only one domain has its drawbacks with error association. So far I've not come up with anything. I also believe users in any case already have the mental model that data fetchers are more or less isolated and do not share data between them. If bad comes to worst we can explain this behavior in the docs.
As for the request data processor, it turned out to be even simpler.
transaction.finish()
is still called within the individual data fetcher's scope, so adding the event processor insidecallTracedServerSideDataFetcher
just works: 3141759 👍