fix(plugin): handle exception from Bun.plugin target string coercion#32062
fix(plugin): handle exception from Bun.plugin target string coercion#32062robobun wants to merge 1 commit into
Conversation
|
Updated 6:02 AM PT - Jun 10th, 2026
❌ @robobun, your commit 58e33ca has 1 failures in
🧪 To try this PR locally: bunx bun-pr 32062That installs a local version of the PR into your bun-32062 --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)
WalkthroughThe PR refactors target property parsing in the Bun plugin system to explicitly handle exceptions when string coercion fails. The C++ implementation separates the ChangesPlugin target coercion error handling
🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. 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. 🔧 Infer (1.2.0)src/jsc/bindings/BunPlugin.cppIn file included from src/jsc/bindings/BunPlugin.cpp:1: ... [truncated 2200 characters] ... "src/clang/cFrontend_decl.ml" (inlined), line 54, characters 4-52 Comment |
|
This PR may be a duplicate of:
🤖 Generated with Claude Code |
|
Closing as a duplicate of #31286, which fixes the same missing exception check in setupBunPlugin. That PR is further along: Jarred's review suggestion (toString instead of toStringOrNull) is already applied and its regression test also covers the release-build behavior. This one came from a different fuzzer input hitting the same code path. |
What does this PR do?
Fixes a debug assertion failure (
ASSERTION FAILED: Unexpected exception observed,ExceptionScope.h(61) assertNoException) found by fuzzing, fingerprint890c68dc4cf1789a.In
setupBunPlugin(src/jsc/bindings/BunPlugin.cpp), thetargetoption is coerced withtargetValue.toStringOrNull(globalObject). That coercion can run user JS (toString/valueOf). When it throws, for example whentoStringreturns a non-primitive so OrdinaryToPrimitive raises "No default value",toStringOrNullreturns null and the old code simply skipped the validation block and kept going with the exception still pending. The subsequentcall()into the plugin'ssetupfunction then tripsassertNoExceptionand aborts debug builds.The fix adds
RETURN_IF_EXCEPTIONaftertoStringOrNulland aftertargetJSString->value()(rope resolution can also throw), so the coercion error propagates to the caller as a normal catchable TypeError.Repro that aborted before this change:
How did you verify your code works?
TypeError: No default valuecleanly on a debug build (also underBUN_JSC_validateExceptionChecks=1) instead of asserting.test/js/bun/plugin/plugins.test.ts("handles 'target' whose string coercion throws"). It aborts the unfixed debug build with the exact assertion from the fuzzer (SIGABRT, exit 134) and passes with the fix. Release builds already surfaced the error correctly because JSC bails out at VM entry with a pending exception, so the bug was only observable on debug/ASAN builds.test/js/bun/plugin/plugins.test.tssuite passes with the debug build (30 pass, 1 pre-existing todo).