Commands Fail Silently If Another Process Already Bound to Server Port

[cwarden]

If another process is already bound to g:apex_server_port and it doesn't respond to commands, they fail silently waiting for a response. For example, using the default port of 8888, start up netcat listening on the port: nc -l 8888 Then start vim and use :ApexDeployOpen. vim-force.com sends the command to netcat, and never displays an error.

[neowit]

It is indeed an issue but not sure what can be done about it.

On every :Apex... command vim sends a call to a TCP socket and waits for response. If on the other side of that socket there is something that does not actively rejects connection from vim (like nc -l 8888 in your example) then I am not sure what can be done on vim side to mitigate this.

If you have any suggestions please share.

[cwarden]

Some possibilities are

• modify the protocol between the client and server so the server sends back an acknowledgement when it receives a command from the client
• add a new action like ping to the server that the client can use to verify that it's talking to the server before sending each action
• timeout with an error if the server doesn't respond after some period

[neowit]

Thank you for the suggestions.

timeout with an error if the server doesn't respond after some period

This may be tricky because some SFDC API requests (e.g. deployments) take long time to respond so server would have to be modified to provide some redundant feedback just to signal that it is still working. Will probably require to modify every single command on the server side, not sure I want to go there.

modify the protocol between the client and server so the server sends back an acknowledgement when it receives a command from the client

This probably is the most robust option, but I am not sure it is worth the effort. After all - there is a config variable g:apex_server_port which exists to help avoid situations like this.

• add a new action like ping to the server that the client can use to verify that it's talking to the server before sending each action

This already exists. vim sends ping before every command to see if server is running or needs starting. Same issue - if server accepts the request but returns no response it will just sit and wait.

On second thought - we could potentially introduce a timeout for ping call specifically because server normally returns pong immediately, let me think about this...