search

pythonic-emacs / anaconda-mode

Code navigation, documentation lookup and completion for Python.
GNU General Public License v3.0
707 stars 87 forks source link

error connection-failed failed with code 22 #378

Closed maxbeegee closed 4 years ago

maxbeegee commented 4 years ago

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 commented 4 years ago

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

maxbeegee commented 4 years ago

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

CeleritasCelery commented 4 years ago

@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 commented 4 years ago

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: https://github.com/pythonic-emacs/anaconda-mode/issues/376#issuecomment-568297406

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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

@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:

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

If I'm right then the following patch should resolve the issue https://github.com/falloutphil/anaconda-mode/commit/58dc748536ab1073624f4499cb14f76bb7095304 - @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 commented 4 years ago

With 1e020c4 it works! 👍

falloutphil commented 4 years ago

I've created a PR for this: https://github.com/pythonic-emacs/anaconda-mode/pull/379

I've made the assumption you need https://github.com/falloutphil/anaconda-mode/commit/58dc748536ab1073624f4499cb14f76bb7095304 as well as https://github.com/falloutphil/anaconda-mode/commit/1e020c463fa1e3c12957526a1c74bcf180768ba5 as there's a syntax error in https://github.com/falloutphil/anaconda-mode/commit/1e020c463fa1e3c12957526a1c74bcf180768ba5 that is corrected.

@CeleritasCelery could you review - it is essentially a one-line change as described here: https://github.com/pythonic-emacs/anaconda-mode/issues/378#issuecomment-578525910

CeleritasCelery commented 4 years ago

Closed with #379