Console's offline flow seems broken with R when lldb is involved (Ark development, or R packages with C++)

[DavisVaughan]

I've been having problems with the R is offline, waiting to reconnect + R reconnected flow.

It will often say it has reconnected but the Console is totally dead in the water, I can type but Enter won't have any affect. The code you see my type here sticks around even after pressing Enter.

test.mov

A few things of note:

• The kernel supervisor sees us go offline, but then also flips us back to idle after the debugger "releases" ark, here are the logs:

15:56:18 [ERROR] [session r-963c060a] No heartbeat response received after 5s, marking kernel as offline.
15:56:18 [DEBUG] (12) kcserver::kernel_state: [session r-963c060a] status 'busy' => 'offline' (lost heartbeat)
15:56:22 [DEBUG] (12) kcserver::zmq_ws_proxy: [session r-963c060a] Forward from 'IOPub' to WebSocket: comm_msg
15:56:22 [DEBUG] (12) kcserver::zmq_ws_proxy: [session r-963c060a] Forward from 'Shell' to WebSocket: execute_reply
15:56:22 [DEBUG] (12) kcserver::zmq_ws_proxy: [session r-963c060a] Forward from 'IOPub' to WebSocket: comm_msg
15:56:22 [DEBUG] (12) kcserver::zmq_ws_proxy: [session r-963c060a] Forward from 'IOPub' to WebSocket: status
15:56:22 [DEBUG] (12) kcserver::kernel_state: [session r-963c060a] status 'offline' => 'idle' (execute_request)

• It is expected that ark cannot send back heartbeats in this case. lldb is attached to ark and has locked it up, and that is normal behavior here.

• There are no other logs that I can find that suggest that the front end part of the console is registering what I'm typing at all

Here is an easyish way to reproduce a similar problem:

• Start an R console and get the pid with Sys.getpid()
• Start lldb in another terminal and run attach --pid <pid>
• Wait for the R Console to go "offline" over in positron, then exit lldb and detach from the process (or hit c to continue)

In this particular case I don't even get the "online" notification, so possibly this is a slightly different issue, but its basically doing the same thing as my first video.

Screen.Recording.2025-01-27.at.11.22.12.AM.mov

[DavisVaughan]

I'm now remembering the first time I saw this. This is actually extremely annoying for ark developers because this is the exact workflow we use when debugging ark:

• Start R in Positron
• Set a breakpoint in ark code
• Trigger the breakpoint by running R code in the console
• Step through code on the ark side (console goes offline here because debugger has ark locked up as we step through it)
• Finish debugging and release the ark process
• R Console never comes back online on the ark side

So basically we end up having to do a full restart of R after each attempt at debugging the R session in question