In some cases it might get closed but it is not a guarantee like thecomment claims it is.While we could implement this behavior properly we already close theconnection in the caller so it seems unnecessary.

Still need to figure out a way to test both, but we would rather not addthe ability to select the backend through the API.

Since we might add to the map after it closes, tweak the delete to alsorun when the pty closes.I think this also fixes that issue where if you canceled the context youpass into Attach it would not do anything since readConnLoop does notuse 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 yourun `echo hello`), then we would wait for the `version` command tosucceed but it never will because the session is already gone.If we immediately read to the process then we can tell when it has goneaway and we can abort.

Since we used the same var all I did with my other change was use thesame logger anyway.Now it will not have the connection ID, which is correct since thepty is not tied to a single connection.

spikecurtis left a comment

I moved the conn closes back to the lifecycle, too.

We do not really do anything with it other than just return it, and ifwe 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 themutex.Also we should check the state outside since there is technically noguarantee an error is set on a state change (although in practice forclose/done there always is, maybe this should be enforced in some way).

…th-screen

🤦