feat: 🎨 improve logging and error handling

[truehazker]

Summary by CodeRabbit

• New Features

  • Improved server startup with proper signal handling for graceful shutdown
  • Structured error logging enriched with HTTP request context

• Bug Fixes

  • More robust error handling and clearer failure responses for user operations

• Documentation

  • Added guidance on correct logger usage to avoid duplicate logs

• Chores

  • Updated logging-related dependencies and startup wiring

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

Logger integration is upgraded from root app level to a plugin-based approach with signal handling (SIGINT/SIGTERM). A pino dependency is added, error logging enhanced with structured HTTP context, and the users module improved with explicit error handling via try/catch blocks and expanded route metadata. Documentation clarifies logger usage patterns.

Changes

Cohort / File(s)	Summary
Dependency & Configuration package.json	Added runtime dependency pino ^10.1.0; updated dev dependency @types/bun from ^1.3.2 to ^1.3.3
Documentation CHANGELOG.md, README.md	Inserted Unreleased changelog describing logger refactor and error-handling improvements; added "Important Notes on Logger Usage" with correct/incorrect import examples
App Initialization & Error Handling src/main.ts	Reworked error handler to destructure { code, error, request } and log structured object including HTTP context (method, url, referrer); separated app.listen out of initial chain and ensured proper startup logging and signal handling
Users Module src/modules/users/index.ts	Removed global log middleware call; switched logger import to src/common/logger; added try/catch in POST and GET handlers with status(422, {...}) on failure and success logging; expanded route metadata and response schemas for 200 and 422

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

• Attention points:
  • src/main.ts: validate structured logging payload and conditional inclusion of request/http fields; confirm signal handling placement.
  • src/modules/users/index.ts: verify error type guards (UsersModel.createError / UsersModel.getError) and correct status payloads; ensure logger import avoids duplicate logs.
  • package.json: confirm pino version intent and any required runtime initialization.

Poem

🐰 I nibbled at code through the night,

Logs stitched neat and errors light,
Pino hummed beneath the moon,
Signals settled — startup tune,
Users safe, each route in sight.

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'improve logging and error handling' accurately summarizes the main changes across multiple files, including logger integration updates, structured error logging, and enhanced error handling in the users module.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch feature/logger-improvement

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 1797fa9 and 7da2aad.

⛔ Files ignored due to path filters (1)

• bun.lock is excluded by !**/*.lock

📒 Files selected for processing (5)

• CHANGELOG.md (1 hunks)
• README.md (1 hunks)
• package.json (1 hunks)
• src/main.ts (2 hunks)
• src/modules/users/index.ts (2 hunks)

✅ Files skipped from review due to trivial changes (1)

• README.md

🚧 Files skipped from review as they are similar to previous changes (3)

• src/main.ts
• src/modules/users/index.ts
• package.json

🔇 Additional comments (1)

CHANGELOG.md (1)

8-16: Clean and accurate changelog documentation.

The new "Unreleased" section properly documents all PR changes with clear, concise entries that align with the Keep a Changelog format. All four entries accurately reflect the implementation changes (logger plugin integration, signal handling, structured error logging, and users module improvements).

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (3)

README.md (1)

137-149: Logger usage notes align with implementation; consider adding a concrete call example

The guidance about initializing the logger in src/main.ts and importing it from src/common/logger in submodules matches the code and should help avoid duplicate registrations. As a small doc improvement, you might add a one‑line example like log.info('Created user', { userId }); under the “✅ Correct” snippet so readers immediately see the intended call pattern.

src/main.ts (1)

17-32: Global onError logging is solid; consider whether you want a standardized client error shape

The structured log (code + err + HTTP method/url/referrer) is very useful for debugging and lines up with Elysia’s onError usage. Returning error here lets Elysia apply its default error mapping, which is valid, but it also means the exact client‑visible error shape is driven by the framework and the specific error type. If you eventually want tighter control (e.g., always returning a { message, code } payload by error code, or hiding internal messages in production), this hook is the right place to centralize that instead of returning the raw error.

src/modules/users/index.ts (1)

1-2: Route‑level error handling is clearer now; consider logging the root cause and distinguishing expected vs unexpected errors

The new handlers read well: success paths log with log.info, response schemas are explicit (200/422), and using status(422, …) with UsersModel.*Error plus satisfies keeps things nicely typed.

Two improvements to consider:

1. Log the underlying error before rethrowing 422
   Right now the original failure from UsersService.create/get is discarded, and the global onError only ever sees the 422 status error. Logging the caught error here would preserve the root cause for ops/debugging:

   // POST
   } catch (error) {
     log.error({ err: error }, 'Failed to create user');
     throw status(422, {
       message: 'Failed to create user' satisfies UsersModel.createError,
     });
   }
   
   // GET
   } catch (error) {
     log.error({ err: error }, 'Failed to get users');
     throw status(422, {
       message: 'Failed to get users' satisfies UsersModel.getError,
     });
   }

2. Optionally, distinguish validation/business errors from unexpected server errors
   If UsersService can throw both “expected” domain/validation errors and hard failures (DB outages, coding bugs, etc.), you may want to narrow the catch to known types (e.g., custom errors or status(422, …) thrown from the service) and let unknown exceptions bubble to the global onError as 5xx instead of always returning 422.

Together these keep the external contract (typed 422 responses) while making observability and HTTP semantics more robust.

Also applies to: 10-19, 36-44

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between fd294dc and 1797fa9.

⛔ Files ignored due to path filters (1)

• bun.lock is excluded by !**/*.lock

📒 Files selected for processing (5)

• CHANGELOG.md (1 hunks)
• README.md (1 hunks)
• package.json (1 hunks)
• src/main.ts (2 hunks)
• src/modules/users/index.ts (2 hunks)

🧰 Additional context used

🧬 Code graph analysis (1)

src/main.ts (1)

src/common/logger.ts (1)

• log (4-19)

🔇 Additional comments (3)

CHANGELOG.md (1)

8-15: Unreleased changelog entry clearly reflects the logging/error‑handling work

The new [Unreleased] section accurately captures the logger/plugin integration, signal handling, and users‑module error handling improvements you’re introducing. No changes needed here.

src/main.ts (1)

51-57: Decoupled app.listen from the plugin chain; startup logging remains clear

Moving app.listen out of the method chain keeps the lifecycle configuration (plugins, hooks, routes) separate from startup concerns, and the callback still logs hostname/port plus the development flag, so behavior remains clear and easy to extend (e.g., adding more startup diagnostics later).

package.json (1)

24-25: Pino dependency is fully compatible with elysia-logger peer requirements

Verification confirms that pino@^10.1.0 satisfies @bogeychan/elysia-logger@^0.1.10's peer dependency requirement of pino >= 9.6.0. No compatibility issues exist. The dependency addition is safe to proceed.