CIDER connects to remote nrepl server instead of localhost

[licht1stein]

Steps to reproduce

1. cider-connect-clj to a remote nrepl over SSH on port 65000
2. Kill that repl.
3. cider-connect-clj to local nrepl on port 65000 (same port as remote).

Expected behavior

CIDER is connected to local nrepl server.

Actual behavior

CIDER is connected to remote SSH nrepl from step 1.

Environment & Version information

CIDER version information

CIDER 1.15.0 (Cogne), nREPL 1.1.0
Clojure 1.12.0-beta1, Java 21.0.3

Lein / Clojure CLI version

Clojure CLI version 1.11.3.1463

Emacs version

GNU Emacs 30.0.50 (build 1, aarch64-apple-darwin22.6.0, NS appkit-2299.70 Version 13.5.2 (Build 22G91)) of 2024-06-01

Operating system

Mac OS 13.5.2

JDK distribution

openjdk 21.0.3 2024-04-16
OpenJDK Runtime Environment Homebrew (build 21.0.3)
OpenJDK 64-Bit Server VM Homebrew (build 21.0.3, mixed mode, sharing)

[vemv]

Thanks for the report!

I might be wrong but it may be because we create a ssh tunnel that doesn't get destroyed after use, something like that.

[licht1stein]

@vemv yes, when this bug happens there is a stray nrepl-tunnel process left. If I kill it with kill-process, the localhost connection works as expected.

[vemv]

Nice!

I've checked recent issues related to nrepl ssh tunnels and there wasn't one for this scenario specifically.

I'm not immediately sure if disposing of this tunnel would be a universally good idea or technically feasible.

(I'm not saying yes/no, just that I don't know).

The safest PR that we'd welcome is one that closed the tunnel after all connections using it were closed and there wasn't something like a sesman-restart in progress.

It still could use a defcustom so that the current behavior isn't changed - approximately like a feature flag.

e.g. defcustom cider-auto-close-ssh-tunnels nil, you'd set it to t, maybe we'd change the default after we'd consider it time-proven.

Of course, if all this was too much of a hassle, you could always just pick different ports for local/remote duties.

[github-actions]

This issue has been automatically marked as stale because it has not had any recent activity. It will be closed soon if no further activity occurs. Thank you for your contribution and understanding!

[licht1stein]

I don't think it's stale