feat(fastify): Update scope transactionName when handling request
#11447
Conversation
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
Lms24
changed the base branch from
develop
to
lms/feat-node-update-scope-transactionName
Lms24
commented
Apr 5, 2024
| expect(transactionEvent).toEqual( | ||
| expect.objectContaining({ | ||
| spans: [ | ||
| { |
There was a problem hiding this comment.
The additional span here is a consequence of us adding another handler. I think this is fine unless someone has concerns.
size-limit report 📦
|
Base automatically changed from
lms/feat-node-update-scope-transactionName
to
develop
April 8, 2024 11:11
Lms24
force-pushed
the
lms/feat-fastify-update-scope-transactionName
branch
from
0f8abff to
2d7ee55
Compare
lforst
reviewed
Apr 8, 2024
| const routeName = reqWithRouteInfo.routeOptions?.url || reqWithRouteInfo.routerPath; | ||
| const method = reqWithRouteInfo.routeOptions?.method || 'GET'; | ||
|
|
||
| getIsolationScope().setTransactionName(`${method} ${routeName}`); |
There was a problem hiding this comment.
I am honestly wondering if we are grabbing the right isolation scope inside these hooks. Gut feeling wise it could I'd say no 🤔
There was a problem hiding this comment.
we should verify this for sure - there may be a race condition if this hook is executed before the http.server span is created, that is correct 😬
There was a problem hiding this comment.
I tested this locally and the isolation scope already seems to be the forked one (i.e. not the default isolation scope). Added a check with a debug log nevertheless to ensure we don't pollute the default isolation scope.
lforst
approved these changes
Apr 9, 2024
cadesalaberry
pushed a commit
to cadesalaberry/sentry-javascript
that referenced
this pull request
Apr 19, 2024
…etsentry#11447) This PR updates the isolation scope's `transactionName` by adding another hook callback in our `setupFastifyErrorHandler` fastify plugin. This is better than accessing the otel span for two reasons: 1. We can always update the transactionName, not just when a span is sampled and recording 2. The `onRequest` hook is executed earlier in the lifecycle than the `preHandler` hook that Otel uses to trigger the `requestHook` callback.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This PR updates the isolation scope's
transactionNamewhenever therequestHookOtel instrumentation hook is invoked and we have a recording span (non-recording spans don't have a attributes :( )Update: Changed the transactionName updating mechanism to adding another hook callback in our
setupFastifyErrorHandlerfastify plugin. This is better than accessing the otel span for two reasons:onRequesthook is executed earlier in the lifecycle than thepreHandlerhook that Otel uses to trigger therequestHookcallback.Also, we now access the same fields to read the route name as Otel.
adjusted existing e2e slightly to cover a paramterized route and to account for the additional span caused by our new
onRequesthandler.ref #10846