Repository navigation
Race condition at the end of hot code replacement causes inconsistent UI state #559
Description
Activity
Hi Ago Kuusik (@akuusik-perforce), I'm an AI Support assistant here to help with your issue. While the team reviews your request, I wanted to provide some possible tips and documentation that might help you in the meantime.
No relevant documentation or existing issues were found that address this specific hot code replacement race condition in the Java debug adapter. It appears to be a new bug in JavaHotCodeReplaceProvider.
Suggested next steps:
- File a new issue in the vscode-java-debug repository, referencing this behavior in
JavaHotCodeReplaceProvider.redefineClasses()and howProtocolServer.sendEventdelaysStoppedEventuntil afterredefineClassescompletes, leading to out-of-order events. - As a temporary workaround, you might consider altering
ProtocolServer.sendEventto flush step-related events immediately rather than batching them until command completion, ensuring thatStoppedEvent/ContinuedEventreach the client in the intended order.
No duplicates were identified among the provided issues.
The team will respond to your issue shortly. I hope these suggestions are helpful in the meantime. If this comment helped you, please give it a 👍. If the suggestion was not helpful or incorrect, please give it a 👎. Your feedback helps us improve!
- File a new issue in the vscode-java-debug repository, referencing this behavior in
At the end of JavaHotCodeReplaceProvider.redefineClasses() execution JavaHotCodeReplaceProvider.stepIntoThread(ThreadReference) is called which sends JDI StepRequest to the target process and subscribes for StepEvent, on reception of which the following events for the UI are populated in that order:
context.getProtocolServer().sendEvent(new Events.StoppedEvent("step", thread.uniqueID())); context.getProtocolServer().sendEvent(new Events.ContinuedEvent(thread.uniqueID()));However, ProtocolServer.sendEvent(DebugEvent) usually reverses this order by putting StoppedEvent to the event queue until ProtocolServer command processing (redefineClasses in this case) has completed. All other types of events are sent immediately. As JDI StepRequest is usually processed very quickly by the target process, the usual order for the VS Code UI to receive the events is ContinuedEvent > StoppedEvent. In contrast, if StepRequest processing happens to be slow then StoppedEvent is sent first and ContinuedEvent as the final one. In that case the Debug toolbar in VS Code UI will be shown like in running state with Stop button while the target process is still suspended.