fix: continue aot error handlers after undefined

[pupuking723]

Fixes #1900

In the AOT route error path, global mapResponse hooks were run after every onError handler, even when the handler returned undefined. That let a logging-only onError be mapped into a response and prevented later onError handlers from producing the intended error response.

This only runs the error-path mapResponse chain when the current onError handler actually returned a value. undefined keeps its existing meaning: the error was not handled yet, so the chain should continue.

Verification:

• npx -y bun test test/lifecycle/error.test.ts -t "continue error handler chain"
• npx -y bun test test/lifecycle/error.test.ts
• npx -y bun run test:types
• git diff --check

Summary by CodeRabbit

• Bug Fixes
  • Fixed error handling to prevent unnecessary response processing when errors are not present, improving application performance and reliability in edge cases.

[coderabbitai]

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: 053f098e-4057-4e0b-ae79-d15c91d257e1

📥 Commits

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

📒 Files selected for processing (2)

• src/compose.ts
• test/lifecycle/error.test.ts

---

Walkthrough

In src/compose.ts, the AOT-generated error handler's mapResponse loop is wrapped in an if(er!==undefined) guard so it only executes when a prior onError hook returned a value. A new parameterized test in test/lifecycle/error.test.ts covers both aot: true and aot: false modes, asserting the correct status, body, and hook invocation order.

Changes

Fix: AOT onError chain + mapResponse guard

Layer / File(s)	Summary
AOT error mapResponse guard and regression test src/compose.ts, test/lifecycle/error.test.ts	Wraps the generated mapResponse loop in if(er!==undefined) so it is skipped when no onError handler produced a response; adds a parameterized it.each([true, false]) test validating the full chain of logger + response-wrapper onError hooks and mapResponse behavior in both AOT and non-AOT modes.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

• elysiajs/elysia#1797: Also modifies the mapResponse handling in the AOT error path of src/compose.ts, specifically around awaited values during mapped error promise flow.
• elysiajs/elysia#1367: Adjusts mapResponse sequencing and trace-aware error handling in the same area of src/compose.ts.
• elysiajs/elysia#1450: Changes error-handling control flow in composeHandler around the onError return value, directly adjacent to the patched code.

Suggested reviewers

• SaltyAom

Poem

Ahh, so undefined was sneaking past mapResponse like it owned the place~? ｡◕‿◕｡
How embarrassing for you, little er... thinking you could just slip through♡
Now there's a guard at the door, ufufu~
if(er!==undefined) says "not today, dummy~" (ง •̀_•́)ง
The chain flows on, proper and correct at laaast~ ♡♡

🚥 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 reflects the core fix: preventing mapResponse execution when onError handlers return undefined in AOT mode.
Linked Issues check	✅ Passed	Changes directly address issue #1900 by fixing the exact problem: continuing onError chain when handlers return undefined instead of executing mapResponse prematurely.
Out of Scope Changes check	✅ Passed	All changes are directly related to fixing the onError chain continuation issue with mapResponse guards; no extraneous modifications detected.
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

Warning

There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure.

🔧 ESLint

If the error stems from missing dependencies, add them to the package.json file. For unrecoverable errors (e.g., due to private dependencies), disable the tool in the CodeRabbit configuration.

ESLint install timed out. The project may have too many dependencies for the sandbox.

---

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

• X
• Mastodon
• Reddit
• LinkedIn

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