Implement hit count breakpoints by lionel- · Pull Request #1087 · posit-dev/ark

lionel- · 2026-03-05T11:36:30Z

Branched from #1086
Addresses posit-dev/positron#12360

Adds support for DAP hit count breakpoints. When a breakpoint has a hitCondition, the breakpoint location must be reached at least that many times before it fires. The value is interpreted as a plain integer with >= semantics. For more complex hit patterns, users can combine hit counts with conditional breakpoints.

Hit counts are reset when ReadConsole returns to a top-level (non-browser) prompt, meaning the execution that may have hit breakpoints is complete. This way counts survive across continue/step within a debug session but start fresh for new sessions.

Hit count integrates with the existing breakpoint feature chain. Hit counts with conditions require both to be satisfied, and hit counts with log messages only emit output once the threshold is reached. If the hit count can't be parsed, the error message is propagated to the Console in breakpoint fences with a clickable link.

QA Notes

Tested on the backend side.

Hit counts should behave well on their own or in combination with logpoints and conditional breakpoints. Parse errors appear in the console.

DavisVaughan

I do think there is an actual bug with the fact that condition should be evaluated before incrementing the hit condition value.

And we should probably think about implementing as a bare number vs a boolean expression, as I mention below

But overall looks quite nice and is something I've definitely wanted in RStudio for a long long time!

DavisVaughan · 2026-03-06T21:36:08Z

        // here, but only containing high-level information such as `search()`
        // contents and `ls(rho)`.
        if !self.debug_is_debugging && !matches!(info.kind, PromptKind::InputRequest) {
+            self.debug_dap.lock().unwrap().reset();


So we do this every time we come through read-console at top level?

Is there any way to only do it after we exit the debugger?

Just curious. I know it's probably not performance sensitive at all right now, I'm just wondering if we can only call this when we really need it.

This is the right place, for this purpose we only know a debug session has finished when we come back to a non-debug prompt.

DavisVaughan · 2026-03-06T21:39:37Z

        return Ok(RObject::from(false).sexp);
    }

+    let hit_count = dap.increment_hit_count(&uri, id);


Just a random thought that this function is called ps_should_break and that makes me think its a simple yes/no kind of thing, but man it's doing way more now! I wonder if there is a better name we can come up with.

Good point, I had the same feeling. It's now handle_breakpoint().

DavisVaughan · 2026-03-06T21:42:47Z

                        injected: false,
                        condition: bp.condition.clone(),
                        log_message: bp.log_message.clone(),
+                        hit_condition: bp.hit_condition.clone(),


I would not be opposed to parsing hit_condition as an integer here so you don't have to do it at each should-break step

That'd be less user friendly because then users don't get parse error messages in a breakpoint block in the Console.

DavisVaughan · 2026-03-06T21:43:40Z

@@ -497,6 +498,8 @@ impl<R: Read, W: Write> DapServer<R, W> {
                        injected: false,
                        condition: bp.condition.clone(),
                        log_message: bp.log_message.clone(),


I'd like to call out that the docs suggest

The expression that controls how many hits of the breakpoint are ignored.

To me that means if you set hit_condition = 2, then 2 hits should be ignored, and only on the 3rd does it stop.

But you said its a >= implementation, and that seems to go against that?

Adapters generally use >= or == (and some don't allow simple numbers). Since I've opted for requiring numbers, it makes more sense to go with the former. That's also what's most generally useful.

DavisVaughan · 2026-03-06T21:50:45Z

    // Must drop before calling back into R to avoid deadlock
    drop(dap);

+    if let Some(ref hit_condition) = hit_condition {


Ooooh I believe you have an ordering error!

According to the docs

* If both this property and `condition` are specified, `hitCondition` should * be evaluated only if the `condition` is met, and the debug adapter should * stop only if both conditions are met.

So IIUC, this whole section should come after your should_break early exit!

i.e. if my condition is x > 5 and then i have a hitCondition of 2, then when x <= 5 it should not be incrementing the hitCondition!

This would make for a good test!

Good catch!

DavisVaughan · 2026-03-06T21:55:38Z

    drop(dap);

+    if let Some(ref hit_condition) = hit_condition {
+        match hit_condition.trim().parse::<u64>() {


I also want to call out that I'm not sure that interpreting this as a simple number is how most people implement hit conditions

https://github.com/go-delve/delve/pull/2490/changes#diff-d8611b2d0b4b5d3b08ffb7b8e3f913420120a431d6dfd81c6f2a8221065bdf70R225-R238

It looks like a common way to do this is to allow the user to supply a hit condition of == 5, where you fill in the LHS of the binary expression there with the current hitCount.

Then users could supply > 5 as well, for "break every time after 5 hits"

You'd support a limited set of options, like ==, >, >=, <, <=, and that would maybe be enough.

Then again, some people do what you did

https://github.com/mfussenegger/nvim-dap/blob/a9d8cb68ee7184111dc66156c4a2ebabfbe01bc5/doc/dap.txt#L808

yep the agent initially implemented a small parser along these lines, but that seemed a bit overkill to me. I thought we'd start with a simple >= interpretation.

lionel- requested a review from DavisVaughan March 5, 2026 11:46

lionel- mentioned this pull request Mar 6, 2026

Implement log breakpoints #1086

Merged

DavisVaughan approved these changes Mar 6, 2026

View reviewed changes

lionel- mentioned this pull request Mar 8, 2026

R debugger: Implement fancy breakpoints posit-dev/positron#12360

Closed

lionel- force-pushed the feature/log-breakpoints branch from 1fb6c9b to 48fb3aa Compare March 8, 2026 17:15

lionel- force-pushed the feature/hit-count branch from c46455e to 542663f Compare March 8, 2026 20:32

lionel- force-pushed the feature/log-breakpoints branch from 04f45bb to 22a9677 Compare March 8, 2026 20:40

Base automatically changed from feature/log-breakpoints to main March 8, 2026 20:40

lionel- added 5 commits March 8, 2026 21:41

Implement hit count breakpoints

36ad482

Reset breakpoint hit counts after reaching top-level

431fd65

Fix rebase issues

9d9f101

Rename to handle_breakpoint()

eda4934

Fix conditional hit condition increment

e559ab2

lionel- force-pushed the feature/hit-count branch from 542663f to e559ab2 Compare March 8, 2026 20:41

lionel- merged commit 4835a67 into main Mar 8, 2026
9 checks passed

lionel- deleted the feature/hit-count branch March 8, 2026 20:42

github-actions Bot locked and limited conversation to collaborators Mar 8, 2026

Conversation

lionel- commented Mar 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

QA Notes

Uh oh!

DavisVaughan left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lionel- Mar 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

lionel- commented Mar 5, 2026 •

edited

Loading

lionel- Mar 8, 2026 •

edited

Loading