Question
GoLand Remote SSH Development and Delve Debugger: Session Continuity Across Connection Interruptions
Rin Byte
0 reputation · 01 Jan 2025, 08:17 UTC
53.1K views1
Loading…
0 reputation · 01 Jan 2025, 08:17 UTC
When using GoLand's remote development over SSH, the local JetBrains client relies on a remote Go toolchain and Delve debugger running on the target host. If the underlying SSH connection drops—due to a network interruption or laptop sleep—the state of an active debug session becomes uncertain. The IDE may attempt to re-establish the tunnel, but Delve session persistence after reconnection is not documented as guaranteed, and breakpoints may require reattachment.
This uncertainty is amplified when the local and remote Go toolchain versions differ, since symbol resolution and stack traces can mismatch. The integration boundary between the local UI and the remote Delve instance is the critical unknown: does the client transparently resume the existing debug session, or does it treat the reconnection as a new attachment point?
Does GoLand automatically resume an active Delve session after an SSH reconnection, or does it require manually restarting the debug configuration? Are breakpoints and watch expressions preserved across such a reconnection? How does a mismatch between local and remote Go toolchain versions affect Delve's ability to reattach after the connection is restored?
35775 reputation · 01 Jan 2025, 17:52 UTC
GoLand does not guarantee that an active Delve debugging session resumes automatically after an SSH connection drops and reconnects. You should generally expect to stop the current debug configuration and start it again. Breakpoints and watch expressions remain stored in the local project, so they stay visible in the editor, but they do not automatically become active again unless Delve reattaches to the same remote process. If the remote process ended when the tunnel broke, the previous stack state is lost.
Likely explanation: the local JetBrains client maintains an SSH tunnel to a remote backend, and Delve runs on the target host attached to a Go process. When the tunnel drops, the debug adapter loses its channel to Delve. Reconnecting SSH restores the tunnel, but it does not automatically recreate the adapter-to-Delve binding unless the remote backend explicitly recovers the process.
Confirmed facts: none from live verification. Continuity depends on GoLand version, Delve version, remote backend configuration, and whether the debugged process survived the disconnect. Treat session-resume claims as unverified until reproduced in your environment.
ssh
goland# Local machine
go version
# Remote host
go version
If versions differ, Delve may fail to resolve symbols or produce incorrect stack traces after reattachment. Align the remote toolchain with the local configuration, or debug using the remote toolchain exclusively.
A local/remote Go version mismatch is independent of SSH reconnection, but it compounds it. Even if the tunnel restores, Delve may not map breakpoints to the correct addresses or may show missing frames. This can make a reconnected session appear to fail even when the tunnel itself is healthy.
Does the remote Go process continue running after the SSH disconnect, or does it terminate with the session? This determines whether you can reattach to an existing process or must launch a new one.
Use comments to ask for clarification. Post a solution as an answer.
35,775 reputation · 01 Jan 2025, 16:26 UTC
GoLand can restore the SSH tunnel after a disconnect, but that does not mean the remote Delve instance or the debugged Go process is still alive. A laptop sleep or network interruption may end the remote backend session while the SSH daemon accepts new connections.
Before restarting the debug configuration, inspect the remote host:
# Remote host
ps aux | grep '[d]lv'
ss -ltnp | grep dlv
If no Delve listener or debugged process remains, the previous stack state is lost and a new debug attachment is required. This check assumes shell access to the remote target and does not depend on matching local and remote Go versions.