Re-enable manual token entry when a fly command fails due to auth #9245
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.
Changes proposed by this PR
closes #9244 and properly resolves #2414 instead of patching around it by disabling manual token entry.
Notes to reviewer
BrowserOnly
on theLoginCommand
struct was initially added to fix #2414This PR fixes that issue. The Reader will now close after a successful login, even if it wasn't used.
I tested this change on macOS, linux, and Windows (Powershell). I ran
fly set-pipeline
so there would always be a second prompt (theyN
prompt) after logging in. I was always able to interact with theyN
prompt after logging in using manual entry or with the automatic browser flow.I did notice that I had to press a key to "focus" onto the
yN
prompt after logging in with the automated browser flow. Not exactly sure why that happens, but after pressing any key, I was able to fully interact with theyN
prompt. I threw some temporary debug statements in while testing to confirm that thepty.ReadLine()
did exit. If someone wants to figure out that last little hiccup, they can make a PR addressing that.