Add sentry error reporting #2309
Conversation
|
WalkthroughThis change set integrates Sentry error tracking and monitoring into a Remix-based web application. It updates the build process, Dockerfile, and GitHub workflow to include Sentry-specific build arguments, secrets, and source map generation and upload. The runtime is enhanced with a new Sentry initialization module and improved error handling that wraps existing error handlers with Sentry reporting. Logger functionality is extended to capture and report errors to Sentry globally. A new admin-only API route simulates errors for testing. Dependencies are updated to add Sentry packages and remove a previous monitoring tool. A shell script automates source map uploads to Sentry during deployment. Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20–25 minutes Complexity label: Moderate Note ⚡️ Unit Test Generation is now available in beta!Learn more here, or try it out under "Finishing Touches" below. 📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (25)
✨ Finishing Touches🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
apps/webapp/app/routes/admin.api.v1.simulate-error.ts (1)
11-11: LGTM! Simple error simulation for testing.The intentional error throw serves its purpose for testing Sentry integration. Consider making the error message more descriptive to help distinguish it in error reports.
Consider making the error message more descriptive:
- throw new Error("Test error"); + throw new Error("Simulated error for testing Sentry integration");
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (6)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yamlreferences/effect/.gitignoreis excluded by!references/**references/effect/package.jsonis excluded by!references/**references/effect/src/trigger/effect.tsis excluded by!references/**references/effect/trigger.config.tsis excluded by!references/**references/effect/tsconfig.jsonis excluded by!references/**
📒 Files selected for processing (10)
.github/workflows/publish-webapp.yml(1 hunks)apps/webapp/app/entry.server.tsx(2 hunks)apps/webapp/app/routes/admin.api.v1.simulate-error.ts(1 hunks)apps/webapp/app/services/logger.server.ts(1 hunks)apps/webapp/package.json(5 hunks)apps/webapp/sentry.server.ts(1 hunks)apps/webapp/server.ts(1 hunks)apps/webapp/upload-sourcemaps.sh(1 hunks)docker/Dockerfile(2 hunks)packages/core/src/logger.ts(2 hunks)
🧰 Additional context used
📓 Path-based instructions (4)
**/*.{ts,tsx}
📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)
**/*.{ts,tsx}: Always prefer using isomorphic code like fetch, ReadableStream, etc. instead of Node.js specific code
For TypeScript, we usually use types over interfaces
Avoid enums
No default exports, use function declarations
Files:
apps/webapp/server.tsapps/webapp/app/routes/admin.api.v1.simulate-error.tsapps/webapp/sentry.server.tsapps/webapp/app/entry.server.tsxapps/webapp/app/services/logger.server.tspackages/core/src/logger.ts
{packages/core,apps/webapp}/**/*.{ts,tsx}
📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)
We use zod a lot in packages/core and in the webapp
Files:
apps/webapp/server.tsapps/webapp/app/routes/admin.api.v1.simulate-error.tsapps/webapp/sentry.server.tsapps/webapp/app/entry.server.tsxapps/webapp/app/services/logger.server.tspackages/core/src/logger.ts
apps/webapp/**/*.{ts,tsx}
📄 CodeRabbit Inference Engine (.cursor/rules/webapp.mdc)
apps/webapp/**/*.{ts,tsx}: In the webapp, all environment variables must be accessed through theenvexport ofenv.server.ts, instead of directly accessingprocess.env.
When importing from@trigger.dev/corein the webapp, never import from the root@trigger.dev/corepath; always use one of the subpath exports as defined in the package's package.json.
Files:
apps/webapp/server.tsapps/webapp/app/routes/admin.api.v1.simulate-error.tsapps/webapp/sentry.server.tsapps/webapp/app/entry.server.tsxapps/webapp/app/services/logger.server.ts
apps/webapp/app/services/**/*.server.ts
📄 CodeRabbit Inference Engine (.cursor/rules/webapp.mdc)
For testable services, separate service logic and configuration, as exemplified by
realtimeClient.server.ts(service) andrealtimeClientGlobal.server.ts(configuration).
Files:
apps/webapp/app/services/logger.server.ts
🧠 Learnings (9)
apps/webapp/server.ts (9)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/app/**/*.test.{ts,tsx} : Test files in the webapp should not import env.server.ts, either directly or indirectly. Tests should only import classes and functions from files matching app/**/*.ts of the webapp, and those files should not use environment variables directly; everything should be passed through as options instead.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/**/*.{ts,tsx} : In the webapp, all environment variables must be accessed through the env export of env.server.ts, instead of directly accessing process.env.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/**/*.{ts,tsx} : When importing from @trigger.dev/core in the webapp, never import from the root @trigger.dev/core path; always use one of the subpath exports as defined in the package's package.json.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/app/v3/presenters/**/*.server.ts : Favor the use of 'presenters' to move complex loader code into a class, as seen in app/v3/presenters/**/*.server.ts.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/app/services/**/*.server.ts : For testable services, separate service logic and configuration, as exemplified by realtimeClient.server.ts (service) and realtimeClientGlobal.server.ts (configuration).
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/app/**/*.test.{ts,tsx} : Tests in the webapp should only import classes and functions from files matching app/**/*.ts, and those files should not use environment variables directly; all configuration should be passed as options.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-07-18T17:49:24.458Z
Learning: Applies to {packages/core,apps/webapp}/**/*.{ts,tsx} : We use zod a lot in packages/core and in the webapp
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-07-18T17:49:24.458Z
Learning: Applies to **/*.{ts,tsx} : No default exports, use function declarations
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : Tasks must be exported, even subtasks in the same file.
apps/webapp/app/routes/admin.api.v1.simulate-error.ts (2)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/app/v3/presenters/**/*.server.ts : Favor the use of 'presenters' to move complex loader code into a class, as seen in app/v3/presenters/**/*.server.ts.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/app/**/*.test.{ts,tsx} : Tests in the webapp should only import classes and functions from files matching app/**/*.ts, and those files should not use environment variables directly; all configuration should be passed as options.
.github/workflows/publish-webapp.yml (2)
Learnt from: nicktrn
PR: #2195
File: .github/workflows/release-helm.yml:42-46
Timestamp: 2025-06-25T13:24:23.836Z
Learning: In .github/workflows/release-helm.yml, the user nicktrn confirmed that using 'entrypoint' with 'docker://' steps works fine, contrary to previous analysis suggesting it's unsupported.
Learnt from: zvictor
PR: #1686
File: packages/build/src/extensions/python.ts:110-116
Timestamp: 2025-02-10T10:56:31.402Z
Learning: In Docker build contexts for Trigger.dev extensions, avoid over-engineering security measures when handling user-provided configuration (like Python requirements) as the build context is already isolated and the content is user-controlled.
apps/webapp/sentry.server.ts (3)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/**/*.{ts,tsx} : In the webapp, all environment variables must be accessed through the env export of env.server.ts, instead of directly accessing process.env.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/app/services/**/*.server.ts : For testable services, separate service logic and configuration, as exemplified by realtimeClient.server.ts (service) and realtimeClientGlobal.server.ts (configuration).
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/app/**/*.test.{ts,tsx} : Test files in the webapp should not import env.server.ts, either directly or indirectly. Tests should only import classes and functions from files matching app/**/*.ts of the webapp, and those files should not use environment variables directly; everything should be passed through as options instead.
apps/webapp/app/entry.server.tsx (1)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/**/*.{ts,tsx} : In the webapp, all environment variables must be accessed through the env export of env.server.ts, instead of directly accessing process.env.
apps/webapp/app/services/logger.server.ts (4)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When logging in tasks, use the logger API (logger.debug, logger.log, logger.info, logger.warn, logger.error) as shown.
Learnt from: nicktrn
PR: #1353
File: apps/webapp/app/v3/services/alerts/deliverAlert.server.ts:76-76
Timestamp: 2024-10-12T01:08:24.066Z
Learning: When extending the Error class in JavaScript/TypeScript, it's not necessary to manually set the name property because it defaults to the class name.
Learnt from: nicktrn
PR: #1353
File: apps/webapp/app/v3/services/alerts/deliverAlert.server.ts:76-76
Timestamp: 2024-09-25T09:55:36.536Z
Learning: When extending the Error class in JavaScript/TypeScript, it's not necessary to manually set the name property because it defaults to the class name.
Learnt from: nicktrn
PR: #1418
File: packages/core/src/v3/errors.ts:364-371
Timestamp: 2024-10-18T15:41:52.352Z
Learning: In packages/core/src/v3/errors.ts, within the taskRunErrorEnhancer function, error.message is always defined, so it's safe to directly call error.message.includes("SIGTERM") without additional checks.
docker/Dockerfile (5)
Learnt from: zvictor
PR: #1686
File: packages/build/src/extensions/python.ts:110-116
Timestamp: 2025-02-10T10:56:31.402Z
Learning: In Docker build contexts for Trigger.dev extensions, avoid over-engineering security measures when handling user-provided configuration (like Python requirements) as the build context is already isolated and the content is user-controlled.
Learnt from: zvictor
PR: #1686
File: packages/build/src/extensions/python.ts:85-87
Timestamp: 2025-02-10T10:54:17.345Z
Learning: In Python-related Dockerfiles for trigger.dev, avoid adding explicit Python version pinning as the base image already provides conservative version management. Additional pinning would unnecessarily slow down builds.
Learnt from: nicktrn
PR: #1306
File: .github/workflows/publish-worker.yml:49-61
Timestamp: 2024-09-23T13:34:24.714Z
Learning: In this project, the Docker builds are already fast, and optimizations using BuildKit's cache are unnecessary.
Learnt from: nicktrn
PR: #1306
File: .github/workflows/publish-worker.yml:49-61
Timestamp: 2024-10-12T01:08:24.066Z
Learning: In this project, the Docker builds are already fast, and optimizations using BuildKit's cache are unnecessary.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/executing-commands.mdc:0-0
Timestamp: 2025-07-18T17:49:29.224Z
Learning: Almost all commands in the monorepo should be executed using pnpm run ... from the root of the monorepo.
packages/core/src/logger.ts (6)
Learnt from: nicktrn
PR: #1418
File: packages/core/src/v3/errors.ts:364-371
Timestamp: 2024-10-18T15:41:52.352Z
Learning: In packages/core/src/v3/errors.ts, within the taskRunErrorEnhancer function, error.message is always defined, so it's safe to directly call error.message.includes("SIGTERM") without additional checks.
Learnt from: nicktrn
PR: #1387
File: packages/cli-v3/src/executions/taskRunProcess.ts:408-413
Timestamp: 2024-10-12T01:08:24.066Z
Learning: In the parseExecuteError method in packages/cli-v3/src/executions/taskRunProcess.ts, using String(error) to populate the message field works fine and even prepends error.name.
Learnt from: nicktrn
PR: #1387
File: packages/cli-v3/src/executions/taskRunProcess.ts:408-413
Timestamp: 2024-10-07T10:32:30.100Z
Learning: In the parseExecuteError method in packages/cli-v3/src/executions/taskRunProcess.ts, using String(error) to populate the message field works fine and even prepends error.name.
Learnt from: nicktrn
PR: #1353
File: apps/webapp/app/v3/services/alerts/deliverAlert.server.ts:76-76
Timestamp: 2024-10-12T01:08:24.066Z
Learning: When extending the Error class in JavaScript/TypeScript, it's not necessary to manually set the name property because it defaults to the class name.
Learnt from: nicktrn
PR: #1353
File: apps/webapp/app/v3/services/alerts/deliverAlert.server.ts:76-76
Timestamp: 2024-09-25T09:55:36.536Z
Learning: When extending the Error class in JavaScript/TypeScript, it's not necessary to manually set the name property because it defaults to the class name.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When logging in tasks, use the logger API (logger.debug, logger.log, logger.info, logger.warn, logger.error) as shown.
apps/webapp/package.json (12)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/executing-commands.mdc:0-0
Timestamp: 2025-07-18T17:49:29.224Z
Learning: Almost all commands in the monorepo should be executed using pnpm run ... from the root of the monorepo.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to trigger.config.ts : Build extensions such as additionalFiles, additionalPackages, aptGet, emitDecoratorMetadata, prismaExtension, syncEnvVars, puppeteer, ffmpeg, and esbuildPlugin must be configured in trigger.config.ts as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : ALWAYS generate Trigger.dev tasks using the task function from @trigger.dev/sdk/v3 and export them as shown in the correct pattern.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : You MUST use @trigger.dev/sdk/v3 when writing Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : The run function contains your task logic in Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-07-18T17:49:24.458Z
Learning: Applies to **/*.test.{ts,tsx} : Our tests are all vitest
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-07-18T17:49:24.458Z
Learning: Applies to internal-packages/database/**/*.{ts,tsx} : We use prisma in internal-packages/database for our database interactions using PostgreSQL
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : Tasks must be exported, even subtasks in the same file.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using retry, queue, machine, or maxDuration options, configure them as shown in the examples for Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : You MUST export every task, including subtasks, in Trigger.dev task files.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When implementing scheduled (cron) tasks, use schedules.task from @trigger.dev/sdk/v3 and follow the shown patterns.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When triggering a task from backend code, use tasks.trigger, tasks.batchTrigger, or tasks.triggerAndPoll as shown in the examples.
🧬 Code Graph Analysis (2)
apps/webapp/app/routes/admin.api.v1.simulate-error.ts (1)
apps/webapp/app/services/session.server.ts (1)
requireUser(39-62)
apps/webapp/app/entry.server.tsx (4)
packages/core/src/logger.ts (1)
error(69-77)apps/webapp/app/services/logger.server.ts (1)
logger(49-59)apps/webapp/app/v3/tracer.server.ts (1)
logger(101-106)packages/cli-v3/src/utilities/logger.ts (1)
logger(113-113)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (25)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (8, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (2, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (10, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (7, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (1, 10)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (8, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (9, 10)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (3, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (4, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (6, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (5, 10)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (7, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (3, 10)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (6, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (5, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (4, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (1, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (2, 8)
- GitHub Check: units / packages / 🧪 Unit Tests: Packages (1, 1)
- GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - npm)
- GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - pnpm)
- GitHub Check: typecheck / typecheck
- GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - pnpm)
- GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - npm)
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (22)
packages/core/src/logger.ts (2)
26-27: LGTM! Clean implementation of error callback hook.The static
onErrorcallback provides a clean way to integrate external error reporting without modifying the core logging logic.
74-76: LGTM! Proper callback invocation with null-safe check.The callback is correctly invoked after logging with proper null checking to prevent runtime errors.
apps/webapp/server.ts (1)
1-1: LGTM! Correct placement of Sentry initialization.The Sentry import is properly placed at the very beginning to ensure error tracking is initialized before any other application code runs.
apps/webapp/app/routes/admin.api.v1.simulate-error.ts (2)
1-2: LGTM! Proper imports for authentication and Remix types.The imports correctly use the session service and Remix types as expected.
4-9: LGTM! Proper admin authorization check.The authentication and authorization logic is correct - requiring a user and checking admin status with an appropriate 403 response for non-admins.
.github/workflows/publish-webapp.yml (2)
89-91: LGTM! Proper Sentry build arguments configuration.The build arguments correctly configure Sentry with the git SHA as release identifier and appropriate organization/project values.
92-93: LGTM! Secure secret handling for Sentry authentication.The secret is properly referenced from repository secrets and passed securely to the build process.
apps/webapp/upload-sourcemaps.sh (2)
1-2: LGTM! Proper shell script error handling setup.The script correctly uses
set -eo pipefailfor robust error handling.
4-13: LGTM! Comprehensive environment validation and Sentry integration.The script properly validates all required environment variables and provides clear feedback when they're missing. The Sentry CLI workflow (create release, inject, upload, cleanup) follows best practices.
apps/webapp/app/entry.server.tsx (2)
19-19: Good Sentry integration import.The import of
wrapHandleErrorWithSentryis correctly placed and follows the expected Sentry Remix integration pattern.
174-188: Well-structured error handling with contextual logging.The implementation properly:
- Wraps the error handler with Sentry for automatic error capture
- Provides conditional request context when available
- Uses structured logging with the existing logger service
- Handles both Request objects and other error contexts appropriately
apps/webapp/app/services/logger.server.ts (3)
6-6: Good Sentry import for error reporting.Correctly imports the necessary Sentry functions for capturing exceptions and messages.
14-30: Excellent integration with Logger's error callback system.The implementation:
- Properly hooks into the Logger's onError callback mechanism
- Intelligently detects Error objects vs plain messages
- Provides rich context through the extra field
- Uses appropriate Sentry capture methods for different scenarios
32-48: Clean and focused helper functions.Both
extractErrorFromArgsandflattenArgsare:
- Well-named and single-purpose
- Handle edge cases appropriately (undefined args)
- Use appropriate type checking for Error objects
- Follow functional programming patterns
docker/Dockerfile (3)
45-45: Good addition of required packages.Adding
ca-certificatesis appropriate for secure HTTPS connections during the Sentry source map upload process.
50-57: Excellent security improvement with secrets handling.The changes properly:
- Add necessary Sentry build arguments
- Remove sensitive SENTRY_AUTH_TOKEN from build args
- Use environment variables for non-sensitive Sentry configuration
- Prepare for secure token handling via Docker secrets
73-75: Secure implementation of Sentry auth token handling.The use of Docker secrets mount for
SENTRY_AUTH_TOKENis a security best practice that:
- Prevents the token from appearing in build history
- Avoids exposure in environment variables
- Follows Docker's recommended secrets handling approach
apps/webapp/package.json (5)
7-7: Good build script sequencing.The modification to run source map upload after all build steps is appropriate and ensures source maps are generated before upload.
9-11: Proper source map generation enabled.Adding
--sourcemapflags to both remix and server builds correctly enables source map generation for Sentry error tracking with proper source code context.
23-23: Clean source map upload integration.The new
upload:sourcemapsscript properly delegates to a bash script, maintaining separation of concerns and allowing for more complex upload logic.
104-105: Appropriate Sentry dependencies added.The addition of:
@sentry/node-nativefor native Node.js integrations@sentry/remixfor Remix-specific Sentry featuresThese are the correct packages for comprehensive Sentry integration in a Remix application.
220-220: Correct Sentry CLI addition.Adding
@sentry/clias a devDependency is appropriate for build-time source map uploads and release management.
No description provided.