Fix unchecked exception in Bun.plugin when target toString throws#31151
Fix unchecked exception in Bun.plugin when target toString throws#31151robobun wants to merge 1 commit into
Bun.plugin when target toString throws#31151Conversation
|
Updated 4:28 PM PT - May 20th, 2026
❌ @robobun, your commit 9ec2e27 has 9 failures in
🧪 To try this PR locally: bunx bun-pr 31151That installs a local version of the PR into your bun-31151 --bun |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (2)
WalkthroughThis PR hardens exception handling during Bun plugin target validation. Two ChangesPlugin Target Exception Handling
🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Comment |
|
This PR may be a duplicate of:
🤖 Generated with Claude Code |
There was a problem hiding this comment.
LGTM — straightforward RETURN_IF_EXCEPTION guard for a fuzzer-found unchecked exception, with a regression test.
Extended reasoning...
Overview
This PR adds two RETURN_IF_EXCEPTION(throwScope, {}) checks in setupBunPlugin (src/jsc/bindings/BunPlugin.cpp) so that an exception thrown during target string coercion (toStringOrNull / JSString::value) is propagated instead of falling through to constructEmptyObject, which asserts no pending exception. A regression test in test/js/bun/plugin/plugins.test.ts exercises a target whose toString throws and asserts the error surfaces.
Security risks
None. This is purely an exception-propagation correctness fix in argument validation; no auth, crypto, permissions, or untrusted-input parsing changes. If anything it hardens behavior by failing fast on a pending exception rather than continuing in an inconsistent VM state.
Level of scrutiny
Low. The change is two lines of the canonical JSC idiom (RETURN_IF_EXCEPTION after a fallible operation) already used dozens of times in this same file. Placement is correct: the outer check covers toStringOrNull returning nullptr with a pending exception, and the inner check covers value(globalObject) (rope resolution can OOM). No control-flow or semantic changes beyond early-returning the existing exception.
Other factors
- Fuzzer-reported assertion failure with a clear minimized repro in the PR description.
- Regression test added next to the existing "handles invalid 'target'" test, following the same pattern.
- Bug-hunting system found no issues.
- No CODEOWNERS coverage for this path and no outstanding reviewer comments.
What does this PR do?
Fixes an
assertNoException()failure insetupBunPluginfound by Fuzzilli (fingerprinte094de1fac1a5ee5).When
Bun.plugin({ target, setup })is called with atargetvalue whose string coercion throws (e.g. an object with a throwingtoString),toStringOrNullreturnsnullptrand leaves the exception pending. The code then fell through toconstructEmptyObject, which asserts that no exception is pending.Before:
ASSERTION FAILED: !exception()in debug builds.After: the thrown error is propagated to the caller.
How did you verify your code works?
test/js/bun/plugin/plugins.test.ts.