add Sentry API #610
add Sentry API #610
Conversation
|
|
🚨 Potential security issues detected. Learn more about Socket for GitHub ↗︎ To accept the risk, merge this PR and you will not be notified again.
Next stepsWhat is an install script?Install scripts are run when the package is installed. The majority of malware in npm is hidden in install scripts. Packages should not be running non-essential scripts during install and there are often solutions to problems people solve with install scripts that can be run at publish time instead. What's wrong with native code?Contains native code which could be a vector to obscure malicious code, and generally decrease the likelihood of reproducible or reliable installs. Ensure that native code bindings are expected. Consumers may consider pure JS and functionally similar alternatives to avoid the challenges and risks associated with native code bindings. Take a deeper look at the dependencyTake a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support [AT] socket [DOT] dev. Remove the packageIf you happen to install a dependency that Socket reports as Known Malware you should immediately remove it and select a different dependency. For other alert types, you may may wish to investigate alternative packages or consider if there are other ways to mitigate the specific risk posed by the dependency. Mark a package as acceptable riskTo ignore an alert, reply with a comment starting with
|
|
That's a lot of dependencies. What size increase normally raises red flags for you? @Andarist @callingmedic911 @bvaughn |
bvaughn
left a comment
bvaughn
left a comment
There was a problem hiding this comment.
Wow, Yarn lock files are so chatty.
packages/playwright/src/reporter.ts
Outdated
| ...test.source.scope, | ||
| test.source.title, | ||
| ].join("-"); | ||
| return withSentrySync("GetTestExecutionId", () => { |
There was a problem hiding this comment.
I don't think this makes sense> There's no function to wrap here, just an inline array.
packages/playwright/src/reporter.ts
Outdated
| title: test.title, | ||
| scope: test.titlePath().slice(3, -1), | ||
| }; | ||
| return withSentrySync("GetSource", () => { |
There was a problem hiding this comment.
I don't think this makes sense either (same reason as above)
I agree. It surprised me too. |
| }, | ||
| "dependencies": { | ||
| "@sentry/node": "^8.13.0", | ||
| "@sentry/profiling-node": "^8.13.0", |
There was a problem hiding this comment.
ideally, we'd be using the same version range everywhere but right now we are using a mix of ^8.13.0 and ^8.15.0 in this PR
| this.authInfo = authInfo; | ||
| } | ||
|
|
||
| async close() { |
There was a problem hiding this comment.
we should add a call to this to exitTasks here:
packages/playwright/src/reporter.ts
Outdated
| }; | ||
|
|
||
| return this.fixtureData[id]; | ||
| return withSentrySync("GetFixtureData", () => { |
There was a problem hiding this comment.
it could be nice to have some withSentryTracking that could wrap a whole class automatically
| this.initialized = true; | ||
| } | ||
|
|
||
| identify(authInfo: AuthInfo) { |
There was a problem hiding this comment.
this method stays unused - should we be using it somewhere?
| export function initSentry(app: string, version: string | undefined) { | ||
| sentry.initialize(app, version); | ||
| } |
There was a problem hiding this comment.
I feel like this is redundant. All files importing initSentry end up using sentry too so they end up with both initSentry and sentry and the first one could simply be replaced at call sites with sentry.initialize
|
|
||
| constructor() { | ||
| this.deviceId = getDeviceId(); | ||
| this.sessionId = randomUUID(); |
There was a problem hiding this comment.
It would be great to share this between SentryAPI and the logger, this way we could try to correlate both data sources more easily
| Sentry.init({ | ||
| dsn: SENTRY_DSN, | ||
| integrations: [nodeProfilingIntegration()], | ||
| }); |
There was a problem hiding this comment.
I wonder if this alone is enough to send something to Sentry. If yes then perhaps we should not even init this module when process.env.REPLAY_TELEMETRY_DISABLED is truthy
This adds Sentry to the repository in a similar manner as we have done with the logger and mixpanel.
I instrumented the Playwright reporter as well so we can start getting errors in production.
We will still need to use Sentry in other packages (
test-utils,cypress, etc.) and this lays a foundation for that work.Note: I think I have become a bit paranoid about missing dependencies, so I installed the Sentry packages in all the other packages. I think there is probably a more methodical/logical way to do this, but since I don't trust the build step locally, I don't know how to test this methodically.