Skip to content

fix: prevent arbitrary error .code from leaking into onError handler#1818

Open
eL1fe wants to merge 1 commit intoelysiajs:mainfrom
eL1fe:fix/on-error-code-leak
Open

fix: prevent arbitrary error .code from leaking into onError handler#1818
eL1fe wants to merge 1 commit intoelysiajs:mainfrom
eL1fe:fix/on-error-code-leak

Conversation

@eL1fe
Copy link
Copy Markdown

@eL1fe eL1fe commented Mar 25, 2026

Summary

  • Errors with a .code property (e.g. AxiosError, node:fs errors) leaked their .code into onError handler instead of "UNKNOWN"
  • Root cause: codegen checked error.code before error[ERROR_CODE] (Elysia's symbol)

Problem

new Elysia()
  .onError(({ code }) => {
    console.log(code) // "ECONNREFUSED" instead of "UNKNOWN"
  })
  .post('/api', async () => {
    await axios.get('http://unreachable') // throws AxiosError with code: "ECONNREFUSED"
  })

This breaks error handling for anyone using libraries that throw errors with a .code property (axios, node:fs, undici, etc).

Changes

  • src/error.ts: add [ERROR_CODE] symbol to all built-in error classes (NotFoundError, ValidationError, ParseError, InternalServerError, InvalidCookieSignature)
  • src/compose.ts: use only error[ERROR_CODE] ?? "UNKNOWN" in codegen (drop error.code fallback)
  • src/dynamic-handle.ts: same change for dynamic/JIT handler path

Test plan

  • AxiosError-like errors with .code now correctly show "UNKNOWN" in onError
  • Built-in Elysia errors (NOT_FOUND, VALIDATION, PARSE, etc.) still work correctly
  • Custom errors registered via Elysia.error() still work correctly
  • Both AOT and dynamic (aot: false) modes tested
  • All existing tests pass (324 pass, 0 fail)

Fixes #1412

Summary by CodeRabbit

  • Refactor
    • Improved error code resolution mechanisms to enhance resilience when handling different error object structures.

When a handler throws an error with a .code property (e.g. AxiosError
with code "ECONNREFUSED"), Elysia passed that value as the error code
to onError instead of "UNKNOWN". This broke error handling for anyone
using libraries like axios, node:fs, etc.

Root cause: codegen checked error.code before error[ERROR_CODE] (the
Elysia-specific symbol). Fixed by:
1. Adding [ERROR_CODE] symbol to all built-in error classes
2. Using only error[ERROR_CODE] in codegen/dynamic handler, with
   "UNKNOWN" as the sole fallback

Fixes elysiajs#1412
@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai Bot commented Mar 25, 2026

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: fab71495-03ea-47eb-b310-e68311114cfe

📥 Commits

Reviewing files that changed from the base of the PR and between 56310be and d9d41d9.

📒 Files selected for processing (3)
  • src/compose.ts
  • src/dynamic-handle.ts
  • src/error.ts

Walkthrough

The changes introduce a symbol-based property (ERROR_CODE) to framework error classes and update error handlers to derive codes from this symbol with fallback to "UNKNOWN" instead of reading arbitrary code properties on thrown objects.

Changes

Cohort / File(s) Summary
Error Classes
src/error.ts
Added ERROR_CODE symbol property initialized with the corresponding error code string to InternalServerError, NotFoundError, ParseError, InvalidCookieSignature, and ValidationError.
Error Code Resolution
src/compose.ts, src/dynamic-handle.ts
Updated error code extraction logic to prioritize error[ERROR_CODE] over direct error.code property access, falling back to "UNKNOWN" for unknown errors.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

🐰 A symbol so clever, ERROR_CODE bright,
Keeps thrown errors' codes from causing a fright,
No more surprise codes from objects unknown,
Just framework-blessed errors in UNKNOWN tone! 🥕

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately summarizes the main change: preventing arbitrary error .code properties from being passed to the onError handler.
Linked Issues check ✅ Passed The PR fully addresses issue #1412 by adding ERROR_CODE symbols to built-in error classes and updating codegen to prioritize the symbol over arbitrary .code properties.
Out of Scope Changes check ✅ Passed All changes are directly scoped to fixing the error code leak issue: modifications to error classes, composed handlers, and dynamic handler code paths.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with 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.

❤️ Share

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

onError sets code from properties of thrown object, regardless of custom error list

1 participant