New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Persistent Dev Tunnel Stops Responding #400
Comments
Im also experiencing a similar issue running a .net core application |
Do you have an idea of how many hours the tunnel is running for?
Docs links: |
No, sorry, my scenario is I run the test web service on my test system using VS and specify a tunnel, the web service comes up and the tunnel works. I repeatedly start and stop a test client and sleep or hibernate the system. The tunnel survives a sleep/hibernate/resume cycle but somewhere it stops, typically after more than 12 hours. I just tried again using the tunnel I created for this test and it seems to work fine again, so that's news - the failure isn't permanent. I'll have a bash with the command line once it fails again. Incidentally, It's a giant PITA trying to find the URL for a persistent tunnel from the UI, especially an inactive one. Is it easier from the command line? I realize that a temporary tunnel probably does not even have a defined URL until it is started, but that is not the case for persistent tunnels. |
ok @derekbekoe , it failed again which is good news I suppose in that it's at least reproducible (or at any rate, recurring). The tunnel ran for about 4 hours then I put the system to sleep with the web service and devtunnel still running but the test client app stopped. After resuming the system a couple of hours later, the tunnel was no longer responsive. a 'show' command on the tunnel returns:
Having seen tha failure again, I'll go ahead and try one using the CLI as you suggested, stay tuned... |
I tried a tunnel created and initiated via the CLI as in your example above, ran it for a few hours and it worked fine. I suspended the system for a couple of hours with the tunnel and test web service still running, it worked without an issue. Tried hibernate overnight and likewise, the following morning ithe same tunnel still worked. So the only failure I've seen was with VS initiated tunnels. Of course it might be an intermittent problem or my test was somehow insufficient so I'll keep this tunnel going for a while longer and see what happens. |
Aha @derekbekoe the CLI initiated tunnel failed, here's what I saw in the console:
So, I used ctrl-c to kill it and these lines were added.
After that I was able to enter |
Thanks for the detailed response. When attempting to reconnect, if an access token is expired, we do attempt to refresh this. However, this may not be successful in all cases depending on many factors (e.g. when the tunnel disconnected, when the token expires, configurable token lifetimes, conditional access, etc.). With that said, similar to the devtunnel CLI, in Visual Studio you should be able to stop/start your persistent tunnel and still maintain the same url to connect to it. |
ok, possibley the token refresh fails if the system isn't active (meaning it's hibernated or suspended) at the time it needs refreshing, of copurse that might just be coincidence. What's the default token refresh period? Is the refresh process expected to survive hibernate/resume? Should I report VS issues against this repo and if not then where? I'll report them here for now. I''s not clear to me how to stop/start a tunnel using the VS window, also, while the window shows my directly created tunnel it fails to start it, failing with:
The tunnel starts fine with the WebTunnel CLI, though that displays a strange set of update messages, which might be fine, since I don't see them any more so the update may have happened.
But it's now working fine witout the messages so maybe the alarming "No newer package versions are available from the configured sources" is just a routine message. |
Were you intentionally trying to change the protocol of the tunnel?
Those winget messages are expected. |
No, I only use TCP and I didn't realize I even could attempt to change the tunnel protocol! Thanks, I'll (continue to) ignore that Winget message. You didn't answer my question "Should I report VS issues against this repo and if not then where?", I'm fine reporting them here, just don't want to waste anyone's time by reporting them in the wrong place. |
The relevant VS team is already aware and looking to see if there's something better that could be done here for long-running tunnels. In the future though, you can also report it at https://developercommunity.visualstudio.com/VisualStudio if it's related to Visual Studio. |
Thanks, I wasn't sure whether the VS people owned the VS Dev Tunnels GUI or not., I'll report GUI issues to them. The other odd thing about the original problem within VS was that stopping the web service and restarting it did not seem to help and I'd expected it would stop and restart the associated tunnel as well. That brings up a related question - is there an orderly way to stop a tunnel using the CLI? Ctrl-C on the |
Ctrl-C is the best way and when you do that, the CLI does clean-up appropriately before it shuts down. |
ok, thanks, Ctrl-C and restart via CLI whenever a long-running tunnel stops working seems sufficient until the VS automated version starts working reliably. |
I'm also having the same issues with my Persistent Dev Tunnel (using it as .net CORE API for my apps) today. |
I've been trying out Dev Tunnels as a replacement for ngrok but I've run into a problem that persistent tunnels work fine for hours but stop responding after a while. I'm not sure what triggers this, it could be a hibernate/resume on my dev machine, could be that the tunnel is idle overnight, might be something else altogether. The current tunnel I'm trying is at https://zllwmpxn-7190.usw3.devtunnels.ms/, the simplest way to test is just browse to it but if I do that it times out. The DNS entry looks ok:
The tunnel inspection URI works but shows no traffic. It's a public persistent tunnel (see image), but for security I'll recreate it once this problem is resolved.
The tunnel was created using Visual Studio and I am new to this so I may be missing something obvious.
The text was updated successfully, but these errors were encountered: