-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
ref(nextjs): Use integration to add request data to transaction events (
#5703) In most of our Node-based SDKs, we use domains to prevent scope bleed between requests, running the entire wrapped event-handling process inside a single domain. This works because in those cases, there is only one request-handling entry point for us to wrap, so we can stick the entire thing in a single `domain.run()` call and (more or less) rely on the fact that we've got a single, consistent, unique-to-that-request `Scope` object that we're dealing with. We've followed this pattern in the nextjs SDK as well, both in `instrumentServer` and `withSentry`. The new auto-wrapping of data-fetching functions presents a challenge, though, because a single request may involve a number of our wrapped functions running at different points in the request handling process, with no shared (little S) scope between them. While we still use domains when wrapping the data fetchers, a single request may pass through multiple domains during its lifecycle, preventing us from using any given domain as a universal `Scope`-carrier for a single `Scope` instance. One place where this becomes is problem is our use of `addRequestDataToEvent`, which up until now we've just been calling inside a single-request event processor added to the current `Scope`. In this system, each event processor holds a reference to its particular `req` object. In the case of the data-fetchers, however, the `Scope` instance to which we might add such an event processor isn't the same as the one which will be active when the event is being processed, so the current way doesn't work. But given that the only way in which our current, single-request-specific event processors differ is by the request to which they hold a reference, they can be replaced by a single, and universal, event processor, as long as we can access `req` a different way besides keeping it in a closure as we do now. This PR does just that (that is, switches to using a single event processor) for transaction events. First, a reference to `req` is stored in the transaction's metadata (which is then available to event processors as `sdkProcessingMetadata`). Then a new default integration, `RequestData`, pulls `req` out of the metadata and uses it to add a `request` property to the event. Notes: - The options API for the new integration is inspired by, but different from, the options API for our Express request handler. (When we work on cleaning up the request data utility functions as part of fixing #5718, we might consider bringing those options in line with these.) The primary differences are: - The options have been (almost entirely) flattened. (It never made sense that inside of options for request data, you had a `request` key holding a subset of the options.) Now everything is at the same level and only takes a boolean. The one exception is `user`, which can still take a boolean or a list of attributes. - In the handler options, `transaction` can either be a boolean or a `TransactionNamingScheme`. In the integration, it can no longer be a boolean - events are going to have transactions, one way or another, so we shouldn't let people set it to `false`. Further, since it's now not about whether `transaction` is or isn't included, it's been moved out of `include` into its own `transactionNamingScheme` option. (Note that the new option is not yet used, but will be in future PRs.) - `method` has also been moved out of include, and has been hardcoded to `true`, since it's an integral part of naming the request. We currently include it in the transaction name, regardless of the setting, so again here, letting people set it to `false` makes no sense. - Though `req` has been added to transaction metadata everywhere we start transactions, the existing domain/`Scope`-based event processors haven't yet been removed, because this new method only works for transactions, not errors. (Solving that will be the subject of a future PR.) The existing processors have been modified to not apply to transaction events, however. - Though we may at some point use the `RequestData` integration added here in browser-based SDKs as well, both in this PR and in near-term future PRs it will only be used in a Node context. It's therefore been added to `@sentry/node`, to prevent a repeat of the dependency injection mess [we just undid](#5759). - No integration tests were added specifically for this change, because the existing integration tests already test that transaction events include a `request` property, so as long as they continue to pass, we know that using the integration instead of an event processor is working. Ref: #5505
- Loading branch information
1 parent
c072b89
commit 5660d9f
Showing
12 changed files
with
235 additions
and
14 deletions.
There are no files selected for viewing
This file contains 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 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 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 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 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 |
|---|---|---|
| @@ -0,0 +1,70 @@ | ||
| import * as SentryCore from '@sentry/core'; | ||
| import * as SentryTracing from '@sentry/tracing'; | ||
| import { IncomingMessage, ServerResponse } from 'http'; | ||
|
|
||
| import { | ||
| withSentryGetServerSideProps, | ||
| withSentryServerSideGetInitialProps, | ||
| // TODO: Leaving `withSentryGetStaticProps` out for now until we figure out what to do with it | ||
| // withSentryGetStaticProps, | ||
| // TODO: Leaving these out for now until we figure out pages with no data fetchers | ||
| // withSentryServerSideAppGetInitialProps, | ||
| // withSentryServerSideDocumentGetInitialProps, | ||
| // withSentryServerSideErrorGetInitialProps, | ||
| } from '../../src/config/wrappers'; | ||
|
|
||
| const startTransactionSpy = jest.spyOn(SentryCore, 'startTransaction'); | ||
| const setMetadataSpy = jest.spyOn(SentryTracing.Transaction.prototype, 'setMetadata'); | ||
|
|
||
| describe('data-fetching function wrappers', () => { | ||
| const route = '/tricks/[trickName]'; | ||
| let req: IncomingMessage; | ||
| let res: ServerResponse; | ||
|
|
||
| describe('starts a transaction and puts request in metadata if tracing enabled', () => { | ||
| beforeEach(() => { | ||
| req = { headers: {}, url: 'http://dogs.are.great/tricks/kangaroo' } as IncomingMessage; | ||
| res = {} as ServerResponse; | ||
|
|
||
| jest.spyOn(SentryTracing, 'hasTracingEnabled').mockReturnValueOnce(true); | ||
| }); | ||
|
|
||
| afterEach(() => { | ||
| jest.clearAllMocks(); | ||
| }); | ||
|
|
||
| test('withSentryGetServerSideProps', async () => { | ||
| const origFunction = jest.fn(async () => ({ props: {} })); | ||
|
|
||
| const wrappedOriginal = withSentryGetServerSideProps(origFunction, route); | ||
| await wrappedOriginal({ req, res } as any); | ||
|
|
||
| expect(startTransactionSpy).toHaveBeenCalledWith( | ||
| expect.objectContaining({ | ||
| name: '/tricks/[trickName]', | ||
| op: 'nextjs.data.server', | ||
| metadata: expect.objectContaining({ source: 'route' }), | ||
| }), | ||
| ); | ||
|
|
||
| expect(setMetadataSpy).toHaveBeenCalledWith({ request: req }); | ||
| }); | ||
|
|
||
| test('withSentryServerSideGetInitialProps', async () => { | ||
| const origFunction = jest.fn(async () => ({})); | ||
|
|
||
| const wrappedOriginal = withSentryServerSideGetInitialProps(origFunction); | ||
| await wrappedOriginal({ req, res, pathname: route } as any); | ||
|
|
||
| expect(startTransactionSpy).toHaveBeenCalledWith( | ||
| expect.objectContaining({ | ||
| name: '/tricks/[trickName]', | ||
| op: 'nextjs.data.server', | ||
| metadata: expect.objectContaining({ source: 'route' }), | ||
| }), | ||
| ); | ||
|
|
||
| expect(setMetadataSpy).toHaveBeenCalledWith({ request: req }); | ||
| }); | ||
| }); | ||
| }); |
This file contains 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 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 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 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 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 |
|---|---|---|
| @@ -0,0 +1,125 @@ | ||
| // TODO (v8 or v9): Whenever this becomes a default integration for `@sentry/browser`, move this to `@sentry/core`. For | ||
| // now, we leave it in `@sentry/integrations` so that it doesn't contribute bytes to our CDN bundles. | ||
|
|
||
| import { EventProcessor, Hub, Integration } from '@sentry/types'; | ||
|
|
||
| import { | ||
| addRequestDataToEvent, | ||
| AddRequestDataToEventOptions, | ||
| DEFAULT_USER_INCLUDES, | ||
| TransactionNamingScheme, | ||
| } from '../requestdata'; | ||
|
|
||
| type RequestDataOptions = { | ||
| /** | ||
| * Controls what data is pulled from the request and added to the event | ||
| */ | ||
| include: { | ||
| cookies?: boolean; | ||
| data?: boolean; | ||
| headers?: boolean; | ||
| ip?: boolean; | ||
| query_string?: boolean; | ||
| url?: boolean; | ||
| user?: boolean | Array<typeof DEFAULT_USER_INCLUDES[number]>; | ||
| }; | ||
|
|
||
| /** Whether to identify transactions by parameterized path, parameterized path with method, or handler name */ | ||
| transactionNamingScheme: TransactionNamingScheme; | ||
|
|
||
| /** | ||
| * Function for adding request data to event. Defaults to `addRequestDataToEvent` from `@sentry/node` for now, but | ||
| * left injectable so this integration can be moved to `@sentry/core` and used in browser-based SDKs in the future. | ||
| * | ||
| * @hidden | ||
| */ | ||
| addRequestData: typeof addRequestDataToEvent; | ||
| }; | ||
|
|
||
| const DEFAULT_OPTIONS = { | ||
| addRequestData: addRequestDataToEvent, | ||
| include: { | ||
| cookies: true, | ||
| data: true, | ||
| headers: true, | ||
| ip: false, | ||
| query_string: true, | ||
| url: true, | ||
| user: DEFAULT_USER_INCLUDES, | ||
| }, | ||
| transactionNamingScheme: 'methodpath', | ||
| }; | ||
|
|
||
| /** Add data about a request to an event. Primarily for use in Node-based SDKs, but included in `@sentry/integrations` | ||
| * so it can be used in cross-platform SDKs like `@sentry/nextjs`. */ | ||
| export class RequestData implements Integration { | ||
| /** | ||
| * @inheritDoc | ||
| */ | ||
| public static id: string = 'RequestData'; | ||
|
|
||
| /** | ||
| * @inheritDoc | ||
| */ | ||
| public name: string = RequestData.id; | ||
|
|
||
| private _options: RequestDataOptions; | ||
|
|
||
| /** | ||
| * @inheritDoc | ||
| */ | ||
| public constructor(options: Partial<RequestDataOptions> = {}) { | ||
| this._options = { | ||
| ...DEFAULT_OPTIONS, | ||
| ...options, | ||
| include: { | ||
| // @ts-ignore It's mad because `method` isn't a known `include` key. (It's only here and not set by default in | ||
| // `addRequestDataToEvent` for legacy reasons. TODO (v8): Change that.) | ||
| method: true, | ||
| ...DEFAULT_OPTIONS.include, | ||
| ...options.include, | ||
| }, | ||
| }; | ||
| } | ||
|
|
||
| /** | ||
| * @inheritDoc | ||
| */ | ||
| public setupOnce(addGlobalEventProcessor: (eventProcessor: EventProcessor) => void, getCurrentHub: () => Hub): void { | ||
| const { include, addRequestData } = this._options; | ||
|
|
||
| addGlobalEventProcessor(event => { | ||
| const self = getCurrentHub().getIntegration(RequestData); | ||
| const req = event.sdkProcessingMetadata && event.sdkProcessingMetadata.request; | ||
|
|
||
| // If the globally installed instance of this integration isn't associated with the current hub, `self` will be | ||
| // undefined | ||
| if (!self || !req) { | ||
| return event; | ||
| } | ||
|
|
||
| return addRequestData(event, req, { include: formatIncludeOption(include) }); | ||
| }); | ||
| } | ||
| } | ||
|
|
||
| /** Convert `include` option to match what `addRequestDataToEvent` expects */ | ||
| /** TODO: Can possibly be deleted once https://github.com/getsentry/sentry-javascript/issues/5718 is fixed */ | ||
| function formatIncludeOption( | ||
| integrationInclude: RequestDataOptions['include'] = {}, | ||
| ): AddRequestDataToEventOptions['include'] { | ||
| const { ip, user, ...requestOptions } = integrationInclude; | ||
|
|
||
| const requestIncludeKeys: string[] = []; | ||
| for (const [key, value] of Object.entries(requestOptions)) { | ||
| if (value) { | ||
| requestIncludeKeys.push(key); | ||
| } | ||
| } | ||
|
|
||
| return { | ||
| ip, | ||
| user, | ||
| request: requestIncludeKeys.length !== 0 ? requestIncludeKeys : undefined, | ||
| }; | ||
| } |
This file contains 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 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