Delay connecting to dlv until it's listening #1354
Conversation
|
Unsure as to why an unrelated test is failing on one specific go version on Mac, maybe someone with access could restart that travis job? |
|
The travis job has been restarted and it passed
Do you mean VS Code was trying to connect to delve before the api server was listening? |
src/debugAdapter/goDebug.ts
Outdated
| }); | ||
| this.debugProcess.stdout.on('data', chunk => { | ||
| let str = chunk.toString(); | ||
| if (this.onstdout) { this.onstdout(str); } | ||
| if (!serverRunning) { | ||
| if (!serverRunning && str.startsWith('API server listening at: ')) { |
There was a problem hiding this comment.
@derekparker Is there any other recommended way for editors to figure out when to connect the client to dlv other than waiting for the message API server listening at: on the stdout?
There was a problem hiding this comment.
The editor should know the host / port it is trying to connect to, would it be possible to simply retry (potentially w/ backoff, or an upper-bound retry time) the connection until the server is running and accepting connections?
There was a problem hiding this comment.
Yes, that's possible and has come up as one of the solutions when I was discussing with @roblourens
Thanks @derekparker
Yes, that is indeed what was happening. |
|
@DMarby I am a little uncomfortable with checking for the string "API server listening at:". The assumption here is that when delve returns with Does delve ever return with any other kind of data before returning
Also, @lukehoban do you remember why the delay was added before making the connection to delve? |
|
That makes sense! As far as I can tell, nothing is outputted on stdout before the API server listening, so I've removed the string comparison. A better long-term solution would most likely be to attempt connection multiple times like @derekparker suggested, but I think this is a good change until that can be done. |
|
@DMarby Below is the net change in this PR
I agree with the first point. |
|
The issue in #473 occurs when we attempt to connect to dlv before it's ready. |
In that case, our assumption that " nothing is outputted on stdout before the API server listening," is wrong and we will have to add the check on "API server listening" back, correct? |
|
After looking into it further (and testing by adding "-v" as buildFlags to my debug configuration), that gets outputted on stderr rather than stdout as well, so we shouldn't need the api server listening check. |
|
In that case, I would keep the delay as well until we hear back from @lukehoban about the reason the delay was put in the first place. |
|
Fair enough, I've gone ahead and reverted the change that removed the delay. |
|
Awesome, thanks for working on this @DMarby ! |
#473
In a project with external dependencies, debugging hang indefinitely for me as
dlvproduces output while compiling the go code, before it starts the api server.This caused VS Code to attempt to connect to
dlvthe api server was listening.In order to avoid this, and to avoid arbitrary delays in the code, this change makes it so that we wait for
dlvto declare that it's ready to accept connections before attempting to connect.I've removed the calls to connectClient from stderr completely, as there is to my knowledge only two possible situations, both which are covered:
errorandcloselisteners.