feat(debugger): add restart option for attach mode with automatic reconnection #25451
Conversation
Feature: Automatic reconnection for attach mode - Add `restart` option to attach configuration (boolean or timeout in ms) - Automatically reconnect when debug connection is lost - Preserve breakpoints across reconnections with VS Code coordination - Support exponential backoff for reconnection attempts Security fixes: - Add SSRF protection: validate WebSocket URLs to only allow localhost - Add path traversal protection: restrict Unix socket paths to tmpdir - Fix race condition: add try/finally to breakpoint removal cleanup Performance improvements: - Parallelize breakpoint removals using Promise.all() - Replace 50ms setTimeout with process.nextTick() for breakpoint resolution Code quality: - Extract #clearBreakpointsForUrl helper to reduce duplication - Replace magic timeout values with named constants - Add isBreakpointExistsError() helper for robust error detection - Add documentation for DoS protections and reconnection behavior 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
WalkthroughAdds WebSocket/Unix-socket attach validation, automatic reconnection with exponential backoff, breakpoint reapplication and race handling, a public restart for attach sessions, Unix socket path validation, and an updated VS Code extension schema and version. Extends AttachRequest and enables supportsRestartRequest. Changes
Pre-merge checks✅ Passed checks (2 passed)
📜 Recent review detailsConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Disabled knowledge base sources:
📒 Files selected for processing (1)
🧰 Additional context used🧠 Learnings (12)📚 Learning: 2025-11-24T18:37:11.466ZApplied to files:
📚 Learning: 2025-11-24T18:37:30.259ZApplied to files:
📚 Learning: 2025-12-02T05:59:51.485ZApplied to files:
📚 Learning: 2025-11-24T18:37:30.259ZApplied to files:
📚 Learning: 2025-11-24T18:37:30.259ZApplied to files:
📚 Learning: 2025-11-24T18:35:50.422ZApplied to files:
📚 Learning: 2025-11-24T18:37:30.259ZApplied to files:
📚 Learning: 2025-09-03T01:30:58.001ZApplied to files:
📚 Learning: 2025-12-05T19:28:39.534ZApplied to files:
📚 Learning: 2025-11-03T20:40:59.655ZApplied to files:
📚 Learning: 2025-09-20T00:57:56.685ZApplied to files:
📚 Learning: 2025-11-24T18:37:30.259ZApplied to files:
🧬 Code graph analysis (1)packages/bun-debug-adapter-protocol/src/debugger/adapter.ts (1)
🔇 Additional comments (22)
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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (3)
packages/bun-debug-adapter-protocol/src/debugger/adapter.ts(19 hunks)packages/bun-debug-adapter-protocol/src/debugger/signal.ts(2 hunks)packages/bun-vscode/package.json(2 hunks)
🧰 Additional context used
🧠 Learnings (10)
📚 Learning: 2025-11-24T18:37:11.466Z
Learnt from: CR
Repo: oven-sh/bun PR: 0
File: src/js/CLAUDE.md:0-0
Timestamp: 2025-11-24T18:37:11.466Z
Learning: Applies to src/js/{builtins,node,bun,thirdparty,internal}/**/*.{ts,js} : Use `$debug()` for debug logging and `$assert()` for assertions; both are stripped in release builds
Applied to files:
packages/bun-debug-adapter-protocol/src/debugger/signal.ts
📚 Learning: 2025-11-24T18:37:11.466Z
Learnt from: CR
Repo: oven-sh/bun PR: 0
File: src/js/CLAUDE.md:0-0
Timestamp: 2025-11-24T18:37:11.466Z
Learning: Applies to src/js/{builtins,node,bun,thirdparty,internal}/**/*.{ts,js} : Use `process.platform` and `process.arch` for platform detection; these values are inlined and dead-code eliminated at build time
Applied to files:
packages/bun-debug-adapter-protocol/src/debugger/signal.ts
📚 Learning: 2025-10-17T20:50:58.644Z
Learnt from: taylordotfish
Repo: oven-sh/bun PR: 23755
File: src/bun.js/api/bun/socket/Handlers.zig:154-159
Timestamp: 2025-10-17T20:50:58.644Z
Learning: In Bun socket configuration error messages (src/bun.js/api/bun/socket/Handlers.zig), use the user-facing JavaScript names "data" and "drain" instead of internal field names "onData" and "onWritable", as these are the names users see in the API according to SocketConfig.bindv2.ts.
Applied to files:
packages/bun-debug-adapter-protocol/src/debugger/signal.ts
📚 Learning: 2025-11-24T18:35:08.612Z
Learnt from: CR
Repo: oven-sh/bun PR: 0
File: .cursor/rules/dev-server-tests.mdc:0-0
Timestamp: 2025-11-24T18:35:08.612Z
Learning: Applies to test/bake/**/*.test.ts : Use `dev.write()`, `dev.patch()`, and `dev.delete()` to mutate the filesystem instead of `node:fs` APIs, as dev server functions are hooked to wait for hot-reload and notify clients
Applied to files:
packages/bun-debug-adapter-protocol/src/debugger/signal.ts
📚 Learning: 2025-09-12T18:16:50.754Z
Learnt from: RiskyMH
Repo: oven-sh/bun PR: 22606
File: src/glob/GlobWalker.zig:449-452
Timestamp: 2025-09-12T18:16:50.754Z
Learning: For Bun codebase: prefer using `std.fs.path.sep` over manual platform separator detection, and use `bun.strings.lastIndexOfChar` instead of `std.mem.lastIndexOfScalar` for string operations.
Applied to files:
packages/bun-debug-adapter-protocol/src/debugger/signal.ts
📚 Learning: 2025-11-24T18:37:11.466Z
Learnt from: CR
Repo: oven-sh/bun PR: 0
File: src/js/CLAUDE.md:0-0
Timestamp: 2025-11-24T18:37:11.466Z
Learning: Applies to src/js/{builtins,node,bun,thirdparty,internal}/**/*.{ts,js} : Use private globals and methods with `$` prefix (e.g., `$Array`, `map.$set()`) instead of public JavaScript globals
Applied to files:
packages/bun-debug-adapter-protocol/src/debugger/signal.ts
📚 Learning: 2025-12-02T05:59:51.485Z
Learnt from: CR
Repo: oven-sh/bun PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-12-02T05:59:51.485Z
Learning: Applies to test/**/*.test.{ts,tsx} : Always use `port: 0` when spawning servers in tests - do not hardcode ports or use custom random port functions
Applied to files:
packages/bun-debug-adapter-protocol/src/debugger/signal.ts
📚 Learning: 2025-11-20T19:51:32.288Z
Learnt from: markovejnovic
Repo: oven-sh/bun PR: 24880
File: packages/bun-vscode/package.json:382-385
Timestamp: 2025-11-20T19:51:32.288Z
Learning: In the Bun repository, dependencies may be explicitly added to package.json files (even when not directly imported in code) to force version upgrades on transitive dependencies, particularly as part of Aikido security scanner remediation to ensure vulnerable transitive dependencies resolve to patched versions.
Applied to files:
packages/bun-vscode/package.json
📚 Learning: 2025-10-19T02:44:46.354Z
Learnt from: theshadow27
Repo: oven-sh/bun PR: 23798
File: packages/bun-otel/context-propagation.test.ts:1-1
Timestamp: 2025-10-19T02:44:46.354Z
Learning: In the Bun repository, standalone packages under packages/ (e.g., bun-vscode, bun-inspector-protocol, bun-plugin-yaml, bun-plugin-svelte, bun-debug-adapter-protocol, bun-otel) co-locate their tests with package source code using *.test.ts files. This follows standard npm/monorepo patterns. The test/ directory hierarchy (test/js/bun/, test/cli/, test/js/node/) is reserved for testing Bun's core runtime APIs and built-in functionality, not standalone packages.
Applied to files:
packages/bun-vscode/package.json
📚 Learning: 2025-11-24T18:37:30.259Z
Learnt from: CR
Repo: oven-sh/bun PR: 0
File: test/CLAUDE.md:0-0
Timestamp: 2025-11-24T18:37:30.259Z
Learning: Applies to test/**/*.test.{ts,js,jsx,tsx,mjs,cjs} : Always check exit codes and test error scenarios in error tests
Applied to files:
packages/bun-debug-adapter-protocol/src/debugger/adapter.ts
🧬 Code graph analysis (1)
packages/bun-debug-adapter-protocol/src/debugger/adapter.ts (1)
packages/bun-debug-adapter-protocol/src/debugger/signal.ts (4)
url(60-62)url(187-189)UnixSignal(21-77)TCPSocketSignal(135-204)
🔇 Additional comments (16)
packages/bun-vscode/package.json (1)
280-288: LGTM! Schema addition for restart option is well-defined.The
restartproperty correctly supports bothboolean(for default 10s timeout) andnumber(for custom timeout in ms), matching the protocol-level implementation. The description clearly explains the behavior.packages/bun-debug-adapter-protocol/src/debugger/signal.ts (1)
107-124: LGTM! Path parsing and validation are correctly integrated.The function properly handles both absolute paths and URL-formatted paths, and validates all paths before returning.
packages/bun-debug-adapter-protocol/src/debugger/adapter.ts (14)
26-65: LGTM! Solid SSRF protection for WebSocket URLs.The validation correctly:
- Allows Unix sockets (
ws+unix://)- Restricts to
ws://andwss://protocols- Limits connections to localhost variants only
The exclusion of
0.0.0.0is appropriate since it binds to all interfaces and could be exploited.
183-192: LGTM! Well-documented restart option with appropriate type.The JSDoc clearly explains the different modes and includes important notes about attach-only applicability.
951-969: LGTM! Proper race condition handling with try/finally.The
#removingBreakpointstracking correctly prevents stalebreakpointResolvedevents from re-adding breakpoints that are being removed. The try/finally ensures cleanup even if removal fails.
971-1017: LGTM! Efficient parallel breakpoint removal with proper cleanup.The
Promise.all()approach improves performance, and the#removingBreakpointstracking ensures race-condition safety. The try/finally pattern guarantees state cleanup.
752-810: LGTM! Robust handling of stale and duplicate breakpoints.The implementation properly handles:
- Stale breakpoints from previous sessions via proactive cleanup
- Race conditions with
isBreakpointExistsErrorfallback- Manual
breakpointResolvedtriggering viaprocess.nextTickwhen the script was already parsedThe comment at line 797-799 explains the edge case clearly.
2249-2288: LGTM! Breakpoint data collection handles URL parsing correctly.The URL extraction logic at lines 2262-2264 correctly handles colons in paths (Windows) and URLs with ports by taking everything except the last two colon-separated parts (line and column).
2393-2413: LGTM! Well-defined reconnection constants with DoS protection.The constants provide sensible defaults:
- 10 max attempts prevents infinite loops
- 5-minute max timeout caps total reconnection duration
- Exponential backoff (1s → 10s max with 1.5x multiplier) rate-limits attempts
- 200ms VS Code coordination delay allows proper breakpoint synchronization
2574-2602: LGTM! Exponential backoff with proper timeout handling.The implementation correctly:
- Waits before attempting (giving the server time to restart)
- Uses exponential backoff capped at 10s
- Terminates when the overall timeout is reached
2870-2885: LGTM! URL validation correctly guards the attach entry point.The
validateWebSocketUrlcall at line 2874 ensures all attach operations (initial, restart, reconnect) are protected against SSRF.
3207-3219: LGTM! Robust error detection for breakpoint conflicts.The case-insensitive check with multiple pattern variants handles different error message formats that the debugger might return.
2296-2314: LGTM! Comprehensive stale state cleanup.Clearing all connection-specific state (sources, stack frames, breakpoint IDs, targets, variables) before reconnection prevents stale data from causing issues with the new session.
2430-2441: LGTM! Smart coordination with VS Code's breakpoint handling.This tracking mechanism prevents duplicate breakpoint application by detecting when VS Code has already handled breakpoints during the reconnection window.
2419-2425: LGTM! Proper signal resource cleanup.The
#cleanupSignal()helper ensures signals are properly closed and dereferenced, preventing resource leaks when sessions restart or terminate.
2443-2563: LGTM! Well-structured reconnection flow with comprehensive error handling.The handler correctly:
- Guards against overlapping reconnections and max attempts
- Preserves breakpoint data before clearing state
- Updates VS Code UI immediately (clearing paused state)
- Uses background reconnection with proper .then/.catch/.finally
- Coordinates with VS Code's breakpoint handling before reapplying
The state management order (collect → clear → reconnect → reapply) prevents race conditions.
- Handle #attach failure in restart() by throwing error when connection fails - Remove redundant '..' path traversal check since normalize() already resolves parent directory references 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
There was a problem hiding this comment.
Actionable comments posted: 4
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (2)
packages/bun-debug-adapter-protocol/src/debugger/adapter.ts(19 hunks)packages/bun-debug-adapter-protocol/src/debugger/signal.ts(2 hunks)
🧰 Additional context used
🧠 Learnings (8)
📚 Learning: 2025-11-24T18:37:11.466Z
Learnt from: CR
Repo: oven-sh/bun PR: 0
File: src/js/CLAUDE.md:0-0
Timestamp: 2025-11-24T18:37:11.466Z
Learning: Applies to src/js/{builtins,node,bun,thirdparty,internal}/**/*.{ts,js} : Use `$debug()` for debug logging and `$assert()` for assertions; both are stripped in release builds
Applied to files:
packages/bun-debug-adapter-protocol/src/debugger/signal.ts
📚 Learning: 2025-10-17T20:50:58.644Z
Learnt from: taylordotfish
Repo: oven-sh/bun PR: 23755
File: src/bun.js/api/bun/socket/Handlers.zig:154-159
Timestamp: 2025-10-17T20:50:58.644Z
Learning: In Bun socket configuration error messages (src/bun.js/api/bun/socket/Handlers.zig), use the user-facing JavaScript names "data" and "drain" instead of internal field names "onData" and "onWritable", as these are the names users see in the API according to SocketConfig.bindv2.ts.
Applied to files:
packages/bun-debug-adapter-protocol/src/debugger/signal.ts
📚 Learning: 2025-11-24T18:37:11.466Z
Learnt from: CR
Repo: oven-sh/bun PR: 0
File: src/js/CLAUDE.md:0-0
Timestamp: 2025-11-24T18:37:11.466Z
Learning: Applies to src/js/{builtins,node,bun,thirdparty,internal}/**/*.{ts,js} : Use `process.platform` and `process.arch` for platform detection; these values are inlined and dead-code eliminated at build time
Applied to files:
packages/bun-debug-adapter-protocol/src/debugger/signal.ts
📚 Learning: 2025-11-24T18:35:08.612Z
Learnt from: CR
Repo: oven-sh/bun PR: 0
File: .cursor/rules/dev-server-tests.mdc:0-0
Timestamp: 2025-11-24T18:35:08.612Z
Learning: Applies to test/bake/**/*.test.ts : Use `dev.write()`, `dev.patch()`, and `dev.delete()` to mutate the filesystem instead of `node:fs` APIs, as dev server functions are hooked to wait for hot-reload and notify clients
Applied to files:
packages/bun-debug-adapter-protocol/src/debugger/signal.ts
📚 Learning: 2025-10-19T04:55:33.099Z
Learnt from: theshadow27
Repo: oven-sh/bun PR: 23798
File: test/js/bun/http/node-telemetry.test.ts:27-203
Timestamp: 2025-10-19T04:55:33.099Z
Learning: In test/js/bun/http/node-telemetry.test.ts and the Bun.telemetry._node_binding API, after the architecture refactor, the _node_binding interface only contains two methods: handleIncomingRequest(req, res) and handleWriteHead(res, statusCode). The handleRequestFinish hook and other lifecycle hooks were removed during simplification. Both current methods are fully tested.
Applied to files:
packages/bun-debug-adapter-protocol/src/debugger/signal.ts
📚 Learning: 2025-09-12T18:16:50.754Z
Learnt from: RiskyMH
Repo: oven-sh/bun PR: 22606
File: src/glob/GlobWalker.zig:449-452
Timestamp: 2025-09-12T18:16:50.754Z
Learning: For Bun codebase: prefer using `std.fs.path.sep` over manual platform separator detection, and use `bun.strings.lastIndexOfChar` instead of `std.mem.lastIndexOfScalar` for string operations.
Applied to files:
packages/bun-debug-adapter-protocol/src/debugger/signal.ts
📚 Learning: 2025-12-02T05:59:51.485Z
Learnt from: CR
Repo: oven-sh/bun PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-12-02T05:59:51.485Z
Learning: Applies to test/**/*.test.{ts,tsx} : Always use `port: 0` when spawning servers in tests - do not hardcode ports or use custom random port functions
Applied to files:
packages/bun-debug-adapter-protocol/src/debugger/signal.ts
📚 Learning: 2025-11-24T18:37:30.259Z
Learnt from: CR
Repo: oven-sh/bun PR: 0
File: test/CLAUDE.md:0-0
Timestamp: 2025-11-24T18:37:30.259Z
Learning: Applies to test/**/*.test.{ts,js,jsx,tsx,mjs,cjs} : Always check exit codes and test error scenarios in error tests
Applied to files:
packages/bun-debug-adapter-protocol/src/debugger/adapter.ts
🧬 Code graph analysis (1)
packages/bun-debug-adapter-protocol/src/debugger/adapter.ts (1)
packages/bun-debug-adapter-protocol/src/debugger/signal.ts (4)
url(60-62)url(184-186)UnixSignal(21-77)TCPSocketSignal(132-201)
🔇 Additional comments (13)
packages/bun-debug-adapter-protocol/src/debugger/signal.ts (2)
83-102: LGTM! Path validation is secure and well-implemented.The Unix socket path validation correctly prevents path traversal by normalizing the path and ensuring it starts with the temp directory. The comment helpfully explains that
normalize()resolves..segments, making thestartsWithcheck sufficient.
104-121: LGTM! Socket path validation is correctly integrated.The validation is properly placed after parsing the socket path from either a string or URL. The error handling provides clear feedback when validation fails.
packages/bun-debug-adapter-protocol/src/debugger/adapter.ts (11)
822-881: Consider verifying breakpoint options match when reusing existing breakpoints.When detecting duplicate requests for the same generated line (lines 834-837), the code reuses the existing breakpoint without verifying that the breakpoint options (condition, hitCondition, logMessage) match. If VS Code sends multiple requests for the same line with different conditions due to a race, reusing the first breakpoint may not reflect the intended configuration.
However, this is likely acceptable since:
- VS Code typically sends a single consolidated request per file
- The race condition this handles is internal (parallel processing of the same request)
- Subsequent
setBreakpointsRequestcalls will replace all breakpoints anywayIf you want to add defensive validation, consider logging a warning in debug mode when options differ.
971-1017: LGTM! Parallel breakpoint removal is well-implemented.The use of
Promise.all()for parallel removal improves performance. The try/finally blocks ensure cleanup even on errors, and the#removingBreakpointsSet correctly prevents race conditions wherebreakpointResolvedfires during removal.
2565-2602: LGTM! Exponential backoff with DoS protection is well-implemented.The reconnection logic correctly implements exponential backoff with rate limiting. The DoS protections listed in the JSDoc (lines 2567-2572) are all properly enforced. The initial delay before the first attempt (line 2580) is appropriate to give the server time to restart.
2604-2625: LGTM! Previous issue with unchecked#attachreturn value has been addressed.The restart method now properly checks if the connection succeeded and throws an error if it fails (lines 2620-2622). This ensures the session doesn't remain in a broken state.
2427-2441: LGTM! VS Code breakpoint coordination is correctly implemented.The override correctly tracks paths that VS Code actively manages during reconnection by checking for non-empty breakpoint arrays (line 2436). This allows selective reapplication of breakpoints for paths VS Code doesn't resend.
2873-2888: LGTM! URL validation prevents SSRF attacks.The addition of
validateWebSocketUrl(url)before connection attempts (line 2877) properly enforces the security policy. The retry logic with backoff (lines 2879-2885) improves connection reliability.
2290-2314: LGTM! Thorough state cleanup prevents stale data issues.The emphasis on clearing sources (lines 2297-2300) is appropriate since stale scriptIds and source maps would cause breakpoint failures after reconnection. Clearing all connection-specific state while preserving breakpoint request data for reapplication is the correct approach.
2316-2337: LGTM! Breakpoint reapplication handles both loaded and unloaded sources.The try/catch (lines 2328-2335) correctly handles the case where sources aren't loaded yet. The comment (lines 2323-2326) clearly explains how placeholder breakpoints at line 0 will be resolved via
Debugger.scriptParsedandDebugger.breakpointResolvedevents.
2225-2239: LGTM! Clearing paused state improves reconnection UX.Emitting the
continuedevent (lines 2234-2237) ensures VS Code updates its UI when the connection is lost while paused. TheallThreadsContinued: trueflag is appropriate since the adapter uses a single-threaded model.
2419-2425: LGTM! Signal cleanup prevents resource leaks.The
#cleanupSignal()method properly releases resources by closing the signal and clearing the reference. Calling it before creating new signals (lines 2720, 2758) and inclose()(line 2646) ensures no signal handlers accumulate.Also applies to: 2646-2646, 2720-2720, 2729-2729, 2757-2757, 2767-2767
2241-2288: The breakpointId parsing should validate line and column numbers before extracting the URL.Lines 2262-2264 split by ":" and blindly assume the last two parts are line and column numbers. This is fragile and could produce incorrect URLs for formats like
file:///C:/path/file.js:10:5. Instead, validate that the last two parts are numeric before reconstructing the URL, or use a more robust parsing method (e.g., regex that captures trailing:(\d+):(\d+)$).
This commit resolves 6 actionable review comments from CodeRabbit:
1. **Remove invalid IPv6 host format**: Removed "[::1]" from allowedHosts array since parsed.hostname returns IPv6 addresses without brackets (e.g., "::1") per WHATWG URL standard.
2. **Remove redundant path traversal check**: Eliminated the normalizedPath.includes("..") check in validateUnixSocketPath since path.normalize() already resolves ".." segments. The startsWith(tempDir) check provides sufficient security.
3. **Handle attach failures in restart()**: Added error handling to check the boolean return value from #attach() and throw a descriptive error when reconnection fails, preventing silent failures that leave the session in a broken state.
4. **Use setImmediate for deferred breakpoint resolution**: Changed from process.nextTick() to setImmediate() to ensure the callback runs after I/O events (including WebSocket messages with Debugger.scriptParsed events) are processed, allowing proper event loop timing.
5. **Implement selective breakpoint reapplication**: Enhanced reconnection logic to reapply only breakpoints for paths NOT handled by VS Code during reconnection, instead of the previous all-or-nothing approach. This preserves breakpoints for files VS Code didn't resend while respecting VS Code's explicit handling of other files.
6. **Add debug logging to isBreakpointExistsError**: Added comprehensive debug logging (gated by isDebug flag) to track which error patterns match or don't match, providing diagnostic information for future debugger protocol changes without affecting production behavior.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
1 participant
Summary
This PR adds support for the
restartoption in attach mode debugging, allowing the VS Code debugger to automatically reconnect when the debug connection is lost. This is particularly useful when debugging applications that restart (e.g., during development with file watchers).Features
restartoption to attach configurationrestart: true- Reconnect with default 10 second timeoutrestart: <number>- Reconnect with specified timeout in milliseconds (max 5 minutes)Security Fixes
Performance Improvements
Promise.all()for removing multiple breakpoints concurrentlysetTimeoutwithprocess.nextTick()for breakpoint resolution timingCode Quality
#clearBreakpointsForUrl()helper method to reduce code duplicationMAX_RECONNECTION_ATTEMPTS,DEFAULT_RECONNECT_TIMEOUT_MS, etc.)isBreakpointExistsError()helper for robust error detection across JSC versions#removingBreakpointsSet to track breakpoints being removed and prevent race conditionsHow to Use
In your VS Code
launch.json, add therestartoption to an attach configuration:```json
{
"type": "bun",
"request": "attach",
"name": "Attach to Bun",
"url": "ws://localhost:6499/",
"restart": true
}
```
Or with a custom timeout:
```json
{
"type": "bun",
"request": "attach",
"name": "Attach to Bun",
"url": "ws://localhost:6499/",
"restart": 30000
}
```
Test Plan
Related
This implements the DAP
supportsRestartRequestcapability for attach mode. For launch mode, the existingwatchModeoption already handles automatic restarts.🤖 Generated with Claude Code
Co-Authored-By: Claude noreply@anthropic.com