Does setBreakpoints trigger multiple breakpoint events?

The breakpoint event says that it "indicates that some information about a breakpoint has changed." Does this only include changes that were internally triggered by the debug adapter, or also changes were triggered externally, like by a setBreakpoints request? For example, if the IDE sends a setBreakpoints request with 5 elements in arguments.breakpoints, should the IDE expect to immediately receive 5 separate breakpoint events from the debug adapter in addition to the setBreakpoints response?

FWIW, the DAP implementation in gdb emitted events in this situation, and we ended up removing them because some clients were not expecting them and would display breakpoints twice.

I'm relying on them actually. But if it is not supposed to work like that I will change my logic.

No. I suggest the following change to clarify this:

interface BreakpointEvent extends Event {
  event: 'breakpoint';

  body: {
    /**
     * The reason for the event.
     * - `changed` indiciates that a breakpoint previously sent to the client
     *   has been updated.
     * - `new` and `removed` indicate that a breakpoint has been added or
     *   removed by the adapter or client action outside of a `setBreakpoints`
     *   request. The client should update its breakpoint list accordingly.
     * 
     * Values: 'changed', 'new', 'removed', etc.
     */
    reason: 'changed' | 'new' | 'removed' | string;

    /**
     * The `id` attribute is used to find the target breakpoint, the other
     * attributes are used as the new values.
     */
    breakpoint: Breakpoint;
  };
}

roblourens

fyi roblourens

Any reason to break out 'changed' in here?

     * - `changed` indiciates that a breakpoint previously sent to the client
     *   has been updated.
     * - `new` and `removed` indicate that a breakpoint has been added or
     *   removed by the adapter or client action outside of a `setBreakpoints`
     *   request. The client should update its breakpoint list accordingly.

The qualifier by the adapter or client action outside of a setBreakpoints request. The client should update its breakpoint list accordingly. could just apply to 'changed' too right?

True, my thinking was it'd be useful for clients to explicitly call out that it's creating/destroying client-side breakpoints, inverting the normal flow of things, since that isn't a common flow implementors would necessarily think about.

The client should update its breakpoint list accordingly.

Text like this should be clear how it affects what is sent in subsequent setBreakpoints requests. Today I found that changed does not affect the data VS Code sends when adding new breakpoints to the file. I'm not sure if that's a bug or not. I've filed #545 for clearer docs in this area

Navigation Menu

Repository navigation

Does `setBreakpoints` trigger multiple `breakpoint` events? #434

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Does setBreakpoints trigger multiple breakpoint events? #434

Description

Activity

tromey commented on Sep 22, 2023

pointhex commented on Sep 22, 2023

connor4312 commented on Aug 7, 2024

connor4312 commented on Aug 7, 2024

roblourens commented on Aug 9, 2024

connor4312 commented on Aug 9, 2024

DanTup commented on Jun 3, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Does `setBreakpoints` trigger multiple `breakpoint` events? #434