fix: use screen for reconnecting terminal sessions if available#8640
Merged
Conversation
a7468cd to
bdd4a6a
Compare
9ae2251 to
59aceb9
Compare
In some cases it might get closed but it is not a guarantee like the comment claims it is. While we could implement this behavior properly we already close the connection in the caller so it seems unnecessary.
Still need to figure out a way to test both, but we would rather not add the ability to select the backend through the API.
Since we might add to the map after it closes, tweak the delete to also run when the pty closes. I think this also fixes that issue where if you canceled the context you pass into Attach it would not do anything since readConnLoop does not use the context for anything but logging.
We want to send the error from failing to wait for the version command, not the error from closing/killing the pty or process.
It is possible for the process to immediately exit (for example if you run `echo hello`), then we would wait for the `version` command to succeed but it never will because the session is already gone. If we immediately read to the process then we can tell when it has gone away and we can abort.
b90c051 to
7a8ec2e
Compare
Since we used the same var all I did with my other change was use the same logger anyway. Now it will not have the connection ID, which is correct since the pty is not tied to a single connection.
spikecurtis
approved these changes
Aug 10, 2023
spikecurtis
left a comment
Contributor
There was a problem hiding this comment.
LGTM.
I do think it would be an improvement to consolidate the bufferedReconnectingPTY down to a single lock, as I mentioned in a comment thread, but what you have now is fine.
I moved the conn closes back to the lifecycle, too.
5f905f5 to
9b88a68
Compare
83ac118 to
9fb4230
Compare
9fb4230 to
d4170ca
Compare
spikecurtis
reviewed
Aug 11, 2023
a83cb61 to
b30bc20
Compare
We do not really do anything with it other than just return it, and if we do need to do something with it we can just do it on the return from `waitForStateOrContext`, we probably would not need to use it behind the mutex. Also we should check the state outside since there is technically no guarantee an error is set on a state change (although in practice for close/done there always is, maybe this should be enforced in some way).
b30bc20 to
88a6b96
Compare
802b2cc to
748cb33
Compare
748cb33 to
968526d
Compare
Member
Author
|
For posterity's sake, I made a mistake because I forgot waiting on the cond releases the lock; hotfix can be found here: #9094 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This fixes #3666 and similar issues.
I copied much of this from v1 (coder/wsep#25) but one major difference is that I was asked to keep the existing behavior as a fallback so I broke out parts into an interface then moved the existing code into said interface.
I think having a fallback makes more sense than it did for v1 since we have macOS and Windows that are not using screen yet (I have not looked into whether screen can run on Windows yet and on macOS it works for me locally but in CI screen will sometimes refuse to find a session even if you
screen -listto verify that exact name does in fact exist).