BLOG-90 Intergrate error tracking with Sentry #120

squid · 2025-08-06T20:17:09+08:00

squid commented

2025-08-06 20:17:09 +08:00

Description

There are several environment variables should be set:

Frontend
- PUBLIC_SENTRY_DSN
- SENTRY_AUTH_TOKEN
Backend
- SENTRY_DSN

If the dsn isn't set, errors won't be sent to Sentry.

Package Changes

No response

Screenshots

Reference

Resolves #90

Checklist

A milestone is set
The related issuse has been linked to this branch

### Description There are several environment variables should be set: - Frontend - `PUBLIC_SENTRY_DSN` - `SENTRY_AUTH_TOKEN` - Backend - `SENTRY_DSN` If the dsn isn't set, errors won't be sent to Sentry. ### Package Changes _No response_ ### Screenshots ![image.png](/attachments/22e49f8d-ac01-4d09-8ff0-7ce87b787055) ### Reference Resolves #90 ### Checklist - [x] A milestone is set - [x] The related issuse has been linked to this branch

image.png

158 KiB

squid added this to the 0.3 milestone 2025-08-06 20:17:09 +08:00

squid added 4 commits 2025-08-06 20:17:09 +08:00

BLOG-90 feat: integrate Sentry for error tracking and performance monitoring

Frontend CI / build (push) Successful in 1m16s

Details

aaf4069cbf

- Added Sentry initialization in both client and server hooks.
- Configured Sentry with environment variables for DSN and sampling rates.
- Implemented error handling with Sentry in server hooks.
- Updated environment configuration to include SENTRY_DSN.
- Configured Vite to upload source maps to Sentry.

BLOG-90 feat: integrate Sentry for error tracking and reporting 1900628a8f

- Added `anyhow` and `sentry` dependencies to the backend and feature crates.
- Introduced `SentryConfiguration` to manage Sentry settings.
- Updated error handling in various services to use `anyhow::Error` for unexpected errors.
- Captured errors using Sentry in the web handlers for better observability.
- Removed specific database error handling in favor of a more generic unexpected error handling.
- Configured Sentry in the main application entry point and wrapped the Actix app with Sentry middleware.

BLOG-90 feat: add common feature and improve error handling across services

Frontend CI / build (push) Successful in 1m11s

Details

beffee8f8e

BLOG-90 refactor: remove 'log' dependency from multiple Cargo.toml files

Frontend CI / build (push) Successful in 1m15s

Details

Auto Comment On PR / add_improve_comment (pull_request) Successful in 18s

Details

PR Title Check / pr-title-check (pull_request) Successful in 16s

Details

5f1f5f43ae

bot commented

2025-08-06 20:17:16 +08:00

/improve

bot commented

2025-08-06 20:17:21 +08:00

PR Code Suggestions ✨

Category	Suggestion	Impact
Possible issue	Handle `Result` from `exchange_code` The `.unwrap()` call will cause the application to panic if `exchange_code` returns an `Err`. This should be handled gracefully by mapping the error to an `AuthError::Unexpected` variant to ensure robust error handling and prevent crashes. backend/feature/auth/src/framework/oidc/auth_oidc_service_impl.rs [83] `-.unwrap() +.map_err(\|e\| AuthError::Unexpected(e.into()))?` Suggestion importance[1-10]: 9 __ Why: The `.unwrap()` call can cause the application to panic, which is undesirable in production. Replacing it with `.map_err(\|e\| AuthError::Unexpected(e.into()))?` correctly leverages the newly introduced `AuthError::Unexpected` variant for robust error handling.	High
General	Return correct HTTP status for errors Several web handlers use a catch-all `_` arm in error matching that converts specific, non-`Unexpected` errors (e.g., `ImageError::NotFound`, `PostError::NotFound`) into `HttpResponse::InternalServerError`. These errors often represent client-side issues (4xx status codes) and should return more appropriate HTTP responses (e.g., `HttpResponse::NotFound()`, `HttpResponse::BadRequest()`) instead of a generic 500. Explicitly match these known error types to return correct status codes. backend/feature/image/src/framework/web/upload_image_handler.rs [85-88] `+ImageError::NotFound => HttpResponse::NotFound().finish(), _ => { capture_anyhow(&anyhow!(e)); HttpResponse::InternalServerError().finish() }` Suggestion importance[1-10]: 8 __ Why: The current `_` catch-all arm in the `upload_image_handler` incorrectly maps `ImageError::NotFound` to an `HttpResponse::InternalServerError`. Explicitly handling `ImageError::NotFound` with `HttpResponse::NotFound()` provides a more accurate and helpful API response.	Medium

## PR Code Suggestions ✨  <table><thead><tr><td><strong>Category</strong></td><td align=left><strong>Suggestion                                                                                                                                    </strong></td><td align=center><strong>Impact</strong></td></tr><tbody><tr><td rowspan=1>Possible issue</td> <td> <details><summary>Handle <code>Result</code> from <code>exchange_code</code></summary> ___ **The <code>.unwrap()</code> call will cause the application to panic if <code>exchange_code</code> returns an <br><code>Err</code>. This should be handled gracefully by mapping the error to an <br><code>AuthError::Unexpected</code> variant to ensure robust error handling and prevent crashes.** [backend/feature/auth/src/framework/oidc/auth_oidc_service_impl.rs [83]](https://git.squidspirit.com/squid/blog/src/branch/BLOG-90_sentry_intergated/backend/feature/auth/src/framework/oidc/auth_oidc_service_impl.rs#L83-L83) ```diff -.unwrap() +.map_err(|e| AuthError::Unexpected(e.into()))? ``` <details><summary>Suggestion importance[1-10]: 9</summary> __ Why: The `.unwrap()` call can cause the application to panic, which is undesirable in production. Replacing it with `.map_err(|e| AuthError::Unexpected(e.into()))?` correctly leverages the newly introduced `AuthError::Unexpected` variant for robust error handling. </details></details></td><td align=center>High </td></tr><tr><td rowspan=1>General</td> <td> <details><summary>Return correct HTTP status for errors</summary> ___ **Several web handlers use a catch-all <code>_</code> arm in error matching that converts specific, <br>non-<code>Unexpected</code> errors (e.g., <code>ImageError::NotFound</code>, <code>PostError::NotFound</code>) into <br><code>HttpResponse::InternalServerError</code>. These errors often represent client-side issues <br>(4xx status codes) and should return more appropriate HTTP responses (e.g., <br><code>HttpResponse::NotFound()</code>, <code>HttpResponse::BadRequest()</code>) instead of a generic 500. <br>Explicitly match these known error types to return correct status codes.** [backend/feature/image/src/framework/web/upload_image_handler.rs [85-88]](https://git.squidspirit.com/squid/blog/src/branch/BLOG-90_sentry_intergated/backend/feature/image/src/framework/web/upload_image_handler.rs#L85-L88) ```diff +ImageError::NotFound => HttpResponse::NotFound().finish(), _ => { capture_anyhow(&anyhow!(e)); HttpResponse::InternalServerError().finish() } ``` <details><summary>Suggestion importance[1-10]: 8</summary> __ Why: The current `_` catch-all arm in the `upload_image_handler` incorrectly maps `ImageError::NotFound` to an `HttpResponse::InternalServerError`. Explicitly handling `ImageError::NotFound` with `HttpResponse::NotFound()` provides a more accurate and helpful API response. </details></details></td><td align=center>Medium </td></tr></tr></tbody></table>

squid merged commit 71bae3d8ca into main

2025-08-06 20:20:47 +08:00

squid deleted branch BLOG-90_sentry_intergated

2025-08-06 20:20:47 +08:00

squid referenced this issue from a commit

2025-08-06 20:20:48 +08:00

BLOG-90 Intergrate error tracking with Sentry (#120)

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: squid/blog#120