Breakpoints for worker bind after the worker has already started #1719
Assignees
Labels
author-verification-requested
Issues potentially verifiable by issue author
bug
Issue identified by VS Code Team member as probable bug
verified
Verification succeeded
Milestone
Comments
connor4312
added a commit
that referenced
this issue
Jun 9, 2023
Some requests can make the client application run slow. If the user tries to resume multiple times when paused and "stuck", it's very easy to get into a bad state. With this change, coalesce multiple requests of the same type together so that clicking resume while stalled doesn't tear the state. I couldn't really get a consistent test case for this since it's timing based :/ Found while investigating #1719
connor4312
added a commit
that referenced
this issue
Jun 9, 2023
connor4312
added a commit
that referenced
this issue
Jun 9, 2023
connor4312
added a commit
that referenced
this issue
Jun 9, 2023
* fix: sourcemap predictor not filtering nested session on windows Fixes #1719 * fix flakiness in pretty print bps test
connor4312
added a commit
that referenced
this issue
Jun 9, 2023
…nt (#1721) * fix: possible bad state when resuming multiple times with a slow client Some requests can make the client application run slow. If the user tries to resume multiple times when paused and "stuck", it's very easy to get into a bad state. With this change, coalesce multiple requests of the same type together so that clicking resume while stalled doesn't tear the state. I couldn't really get a consistent test case for this since it's timing based :/ Found while investigating #1719 * fix tests
roblourens
added
verification-steps-needed
|
Hey @rchiodo, is this working for you now? |
|
Yep, working good. I use it everyday now. |
connor4312
added
verified
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
If your worker map file is too large, breakpoints won't bind until after the worker is already running
To Reproduce
The only steps I have to reproduce is to use our real product. I'm running a worker thread that contains our entire language server and the breakpoints for the worker thread bind on a time delay after the worker has actually started.
Meaning I can't debug startup of the worker thread.
The breakpoints do bind later, and I can debug messages sent to the server (as I can stick a breakpoint in the client).
Log File
vscode-debugadapter-d1089d59.json.gz
VS Code Version: 1.79.0-insiders
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: