error connection-failed failed with code 22

[maxbeegee]

Hi! I've been happily using anaconda-mode for years but after an update it does not work anymore.

In *anaconda-mode* I get

anaconda_mode port 57337

In *anaconda-response*

# status: (:error (error connection-failed deleted
  :host localhost :service 57372) :error (error connection-failed failed with code 22
  :host localhost :service 57372))
 # point: 1

Python packages:

jedi 0.15.2
service_factory 0.1.5
json-rpc 1.13.0

System:

MacOSX 10.14
Emacs 25.3 (spacemacs)
anaconda-mode 20191204.111

I tried to change anaconda-mode-localhost-address to "localhost" and "127.0.0.1" with the same outcome.
I do not run it in a VM / with a proxy / ... (the related issues I've seen here).

Thanks in advance for you help.

[CeleritasCelery]

Can you try reverting to commit 3ede03d and see if that addresses the issue?

[maxbeegee]

Great. That works. Before I had 20191204.111 from elpa. Thanks again!

[CeleritasCelery]

@falloutphil This is the second user (#376) reporting an issue with #357. And here the user fixed the issue by reverting before that commit. Unless we can determine what is wrong I think we will have to revert it again. 😞

[falloutphil]

I recognize this might be a bold comment :-) but the problem here I think might be that users have come accustomed to using broken code in a way that works for them, that was never supposed to work (as previously explained in old threads on this subject).

Hi @maxbeegee - can you confirm you can manually ssh directly from the command line to your remote TRAMP server, if yes, can you then try adding the ssh config as per:
#376 (comment)

Also can you answer all the bullets as per the message linked above into a new comment on this thread - in particular the contents of anaconda-ssh is important to diagnosing the problem. I'd really appreciate this - as I'd love to resolve this once and for all.

Finally can you confirm if the problem is existing immediately for you, or the connection is dropping regularly, but working intermittently?

Thanks!

I am 99% sure that reverted code is wrong, and worse, a security issue - and a few other people have confirmed this behavior too over the last year - by swapping my patch with the reverted code.

I'm willing to change my mind on this, but someone if going to have to explain what the original code does and why - because it makes no sense to me. To my mind it never did (properly) what the original developer intended - which is to tunnel anaconda requests using an external SSH process to Jedi. The fact that it works in some limited scenarios doesn't make my fix a bug, but it is an awkward situation :-)

Assuming I can't fix the problem for @maxbeegee with the feedback requested above, then there is a solution that will keep everyone happy - what do you guys think?:

We need to support both the broken methodology and the new methodology. To do this I'd implement a custom flag which would default to the old methodology, but I would put a warning on this that the code is being transmitted insecurely over the internet. If the new flag something like use-ssh-tunnel is set to true then I'd switch to my new implementation.

I don't like this as we are perpetuating broken code, but from a practical point of view I see no other way of resolving it.

Thoughts?

[CeleritasCelery]

@falloutphil Thanks for being so responsive to this. I know this has to be terribly frustrating 😆. I was not involved in the original discussion so I am counting on you to understand the scope of this change.

but the problem here I think might be that users have come accustomed to using broken code in a way that works for them, that was never supposed to work. I am 99% sure that reverted code is wrong, and worse, a security issue - and a few other people have confirmed this behavior too over the last year - by swapping my patch with the reverted code.

If we make a change to the readme of what the recommended way to run this is that could work. But we need to define what users are doing wrong.

We need to support both the broken methodology and the new methodology. To do this I'd implement a custom flag which would default to the old methodology, but I would put a warning on this that the code is being transmitted insecurely over the internet. If the new flag something like use-ssh-tunnel is set to true then I'd switch to my new implementation. I don't like this as we are perpetuating broken code, but from a practical point of view I see no other way of resolving it.

If we don't get any feedback or can't seem to get to the bottom of this that seems like the only solution. And much better then reverting the change.

[maxbeegee]

@falloutphil thanks for your comment on this. Maybe I misunderstood but just to be clear: I was editing a local file when the problem occurred. I can try to edit a remote file if you want me to...?

[falloutphil]

@maxbeegee - thanks - this helps, and answers most of my questions.

My guess is this is a completely different bug to #376 - which I believe was the tunnel dropping on a remote file operation (and hopefully solved with keep-alive config). So I'll need to investigate this from scratch.

Can you let me know:

• What buffer anaconda-ssh contains (if it exists at all given the file is local) when the error happens?
• Exactly what sequence of anaconda functions/keystrokes you used to get the error message?
• Despite the fact that you clearly shouldn't need it - do you have ssh installed and on your path?

Also if it's not too much trouble if you could try an open a file over TRAMP and see what happens in that case - it might help to further isolate the issue.

Thanks!

[maxbeegee]

• The buffer anconda-ssh does not exist.
• It does not matter. I load a python file. And when I start typing a command / scroll through the file (i.e., whenever anaconda-mode should show some info) the error occurs.
• What do you mean with ssh installed? I am on a Mac so ssh is installed.

I have fixed the issue now reverting to 3ede03d but I can re-revert and try opening a file via TRAMP later this weekend.

[falloutphil]

OK - so it's looking like it's not even trying to create an ssh session (which is correct), but the local "RPC" request is still failing.

What do you mean with ssh installed? I am on a Mac so ssh is installed.

Yep should be fine then, it'll be on your default PATH on a Mac, I believe. I shouldn't be required anyway, and you previous answers suggest this isn't the problem.

Thanks for to looking at the revert later this weekend - much appreciated.

[falloutphil]

I've had a bit more of a think about this.

Given the revert worked, and @maxbeegee is only trying to edit a local file there is only a single change in my commit that should make any difference - the hardcoding of to localhost:

(format "http://localhost:%s" (anaconda-mode-port))

My other changes shouldn't mater

• New defcustom definition is harmless
• New function anaconda-jump-proxy-string is harmless
• The change to anaconda-mode-bootstrap-filter is only called when pythonic-remote-ssh-p is true - hence only if the tramp file method is "ssh", which I'm assuming can only be the case if the file is being accessed over ssh (i.e. it's remote)?

If I'm right then the following patch should resolve the issue falloutphil@58dc748 - @maxbeegee could you give it a whirl?

I've tested this on a local python file on my machine and it works fine, but as I couldn't reproduce the original error, I'll need you to confirm it works for you or not?

[maxbeegee]

With 1e020c4 it works! 👍

[falloutphil]

I've created a PR for this:
#379

I've made the assumption you need falloutphil@58dc748 as well as falloutphil@1e020c4 as there's a syntax error in falloutphil@1e020c4 that is corrected.

@CeleritasCelery could you review - it is essentially a one-line change as described here:
#378 (comment)

[CeleritasCelery]

Closed with #379