Fix deferred capability handling for exception breakpoints#342
Merged
Conversation
PR #328 deferred the entire DAP capabilities payload to a post-connect CapabilitiesEvent, but VS Code reads `exceptionBreakpointFilters` exactly once from the initialize response - so the filters never appeared in the BREAKPOINTS panel. Split the responsibilities: - `initializeRequest` surfaces the filter list (UI-driving, must be early) - post-connect CapabilitiesEvent carries the device-dependent booleans (supportsExceptionFilterOptions/Options, supportsConditionalBreakpoints, supportsHitConditionalBreakpoints, supportsLogPoints), which VS Code reads per-render so CapabilitiesEvent updates take effect Adjacent fixes uncovered while testing: - ProtocolCapabilities class: extract version-based capability checks from DebugProtocolClient. Adapter holds a fallback instance seeded from device-info `brightscriptDebuggerVersion` so we can answer capability questions before the protocol handshake completes. - setExceptionBreakPointsRequest deadlock: was awaiting `getRokuAdapter()` which waits for the device to come online; that waits for publish(), which waits for configurationDone, which VS Code holds until we respond to this request. Switched to awaiting `rokuAdapterDeferred.promise`. - Adapter queues exception breakpoint filters when the debug protocol client hasn't connected yet, replays on connect. - \`_syncBreakpoints\` now gates on \`this.connected\` and a proactive \`syncBreakpoints()\` runs on connect to flush queued breakpoints.
Some Roku firmware versions support the debug protocol but don't report brightscript-debugger-version in device-info. ProtocolCapabilities now takes an optional osVersion and falls back to the OS-to-protocol mapping from the docs when the supplied protocol version is missing or invalid.
TwitchBronBron
approved these changes
May 15, 2026
Member
TwitchBronBron
left a comment
TwitchBronBron
left a comment
There was a problem hiding this comment.
Gave this a quick test, everything seems to be working fine. Nice!
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
PR #328 deferred the entire DAP capabilities payload to a post-connect
CapabilitiesEvent, but VS Code readsexceptionBreakpointFiltersexactly once from the initialize response — so the filters never appeared in the BREAKPOINTS panel.Split the responsibilities:
initializeRequestsurfaces the filter list (UI-driving, must be early)CapabilitiesEventcarries the device-dependent booleans (supportsExceptionFilterOptions/supportsExceptionOptions,supportsConditionalBreakpoints,supportsHitConditionalBreakpoints,supportsLogPoints), which VS Code reads per-render soCapabilitiesEventupdates take effectAdjacent fixes uncovered while testing
ProtocolCapabilitiesclass — extract version-based capability checks fromDebugProtocolClient. The adapter holds a fallback instance seeded from device-infobrightscriptDebuggerVersionso we can answer capability questions before the protocol handshake completes. Some firmware versions support the debug protocol but omitbrightscript-debugger-versionfrom device-info, so the class also takes an optionalsoftwareVersionand derives the protocol version from the Roku OS → protocol mapping when the device-info value is missing.setExceptionBreakPointsRequestdeadlock — was awaitinggetRokuAdapter()which waits for the device to come online; that waits forpublish(), which waits forconfigurationDone, which VS Code holds until we respond to this request. Switched to awaitingrokuAdapterDeferred.promise._syncBreakpointsgating — now gates onthis.connectedand a proactivesyncBreakpoints()runs on connect to flush queued breakpoints.