-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Azure: fall back to powershell when no preferred shell is set #8197
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems like a fair solution to me, but I'm gonna defer to @DHowett and @PankajBhojwani with this one.
if (!shellType.has_value()) | ||
{ | ||
_WriteStringWithNewline(RS_(L"AzureInvalidUserSettings")); | ||
_transitionToState(ConnectionState::Failed); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If they're missing a preferred shell type, is there a way to just fall back to something reasonable, instead of failing entirely? Maybe we could display the warning, but then use PowerShell, and if they want bash
then at least they'll know why powershell was chosen
/cc @DHowett
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@zadjii-msft - absolutely. Actually, I already implemented something similar for: #4987
In that ticket I allow the user to always select a shell, where the preferred one is marked as default.
But I guess that ticket will be stuck on product, because UX is not trivial (extra user input is introduced).
So I can probably adjust the logic from there to here. I.e., read the preferred shell.. if no preferred shell was found - allow the user to select the shell manually.
I will do the adjustment, but hope you help me push it forward 😊
@@ -148,6 +148,10 @@ | |||
<value>You have not set up your cloud shell account yet. Please go to https://shell.azure.com to set it up.</value> | |||
<comment>{Locked="https://shell.azure.com"} This URL should not be localized. Everything else should.</comment> | |||
</data> | |||
<data name="AzureInvalidUserSettings" xml:space="preserve"> | |||
<value>Your cloud shell account misses some mandatory settings. Please go to https://shell.azure.com to set it up.</value> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
<value>Your cloud shell account misses some mandatory settings. Please go to https://shell.azure.com to set it up.</value> | |
<value>Your cloud shell account does not have a default shell configured. Please go to https://shell.azure.com to set it up.</value> |
Perhaps? We'd need to workshop the text if we go with the graceful fallback solution
if (!settingsResponse.has_object_field(L"properties")) | ||
{ | ||
return std::nullopt; | ||
} | ||
|
||
const auto userSettings = settingsResponse.at(L"properties"); | ||
if (!userSettings.has_string_field(L"preferredShellType")) | ||
{ | ||
return std::nullopt; | ||
} | ||
|
||
const auto preferredShellTypeValue = userSettings.at(L"preferredShellType"); | ||
return std::optional(preferredShellTypeValue.as_string()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I might suggest a little more telescoping to make this easier to read:
if (!settingsResponse.has_object_field(L"properties")) | |
{ | |
return std::nullopt; | |
} | |
const auto userSettings = settingsResponse.at(L"properties"); | |
if (!userSettings.has_string_field(L"preferredShellType")) | |
{ | |
return std::nullopt; | |
} | |
const auto preferredShellTypeValue = userSettings.at(L"preferredShellType"); | |
return std::optional(preferredShellTypeValue.as_string()); | |
if (settingsResponse.has_object_field(L"properties")) | |
{ | |
const auto userSettings = settingsResponse.at(L"properties"); | |
if (userSettings.has_string_field(L"preferredShellType")) | |
{ | |
const auto preferredShellTypeValue = userSettings.at(L"preferredShellType"); | |
return preferredShellTypeValue.as_string(); | |
} | |
} | |
return std::nullopt; |
You also shouldn't need to construct an optional directly and instead rely on the optional constructor to let you return a string directly.
If you do need to construct the optional directly, prefer return { blah.as_string() };
😄 so you don't need to repeat the optional type.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sorry, my suggestion text apparently contains tabs (thanks GitHub_)
_WriteStringWithNewline(RS_(L"AzureRequestingTerminal")); | ||
const auto socketUri = _GetTerminal(shellType); | ||
const auto socketUri = _GetTerminal(*shellType); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd say let's just tear off the band-aid and call it:
const auto socketUri = _GetTerminal(*shellType); | |
const auto socketUri = _GetTerminal(shellType.value_or("powershell")); |
We don't need to emit a warning and we don't need to add another resource string 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As above!
I'll get to them in turn 😉 |
Do you mean you want to push both of them? The second one delayed? Since I need to fix the same comments in both branches. |
So, I think that this is a fine fix while we figure out how best to approach #8204. I share your concern about introducing new UI. I had originally thought that we could add support for shell selection by overloading the meaning of commandline for the Azure Cloud Shell connection type. That is -- we could give users the option of setting In the interest of full full disclosure: I really wanted to land a feature that would allow a connection type constructor to see the json blob (or see a representation of the json blob, because I really do not want to push json through WinRT, ESPECIALLY not as a string (ugh)) and in so doing allow the connection class to add support for its own profile options. That would, long-term, allow for something like: {
"connectionType": "{azure-cloud-shell-ctype-guid}",
"shell": "bash",
"tenant": "00001111-4444-5555-6666-777788889999",
"cloud": "US Sovereign Cloud" // or whatever
} so that folks could preconfigure an entire ACS profile that just skips all of the UI/UX/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if (!settingsResponse.has_object_field(L"properties")) | ||
{ | ||
return std::nullopt; | ||
} | ||
|
||
const auto userSettings = settingsResponse.at(L"properties"); | ||
if (!userSettings.has_string_field(L"preferredShellType")) | ||
{ | ||
return std::nullopt; | ||
} | ||
|
||
const auto preferredShellTypeValue = userSettings.at(L"preferredShellType"); | ||
return std::optional(preferredShellTypeValue.as_string()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sorry, my suggestion text apparently contains tabs (thanks GitHub_)
@DHowett - no worries, I am doing it locally.. I also need to test it 😄 . Which I can only do artificially now, since the issue does not reproduce anymore in my subscriptions, so I have to change some eax's in WinDBG Which could be by the way avoided, if we would allow configuring proxy for our connection (then I could test everything with Fiddler and autoresponder). |
_WriteStringWithNewline(RS_(L"AzureRequestingTerminal")); | ||
const auto socketUri = _GetTerminal(shellType); | ||
const auto socketUri = _GetTerminal(shellType.value_or(L"pwsh")); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
neat! i didn't realize pwsh
was the official value for that one 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Love it. Thank you!
@msftbot merge this in 1 minute |
Hello @DHowett! Because you've given me some instructions on how to help merge this pull request, I'll be modifying my merge approach. Here's how I understand your requirements for merging this pull request:
If this doesn't seem right to you, you can tell me to cancel these instructions and use the auto-merge policy that has been configured for this repository. Try telling me "forget everything I just told you". |
Sorry you had to manually recover the client ID ;) |
Shoulder sign-off from @PankajBhojwani:
|
🎉 Handy links: |
Hi, Why must this error message be so unspecific? What key is missing, why can't it use an intelligent default? Really bad experience here for new users. |
@dave-007 I'm sorry you're still hitting this issue. Unfortunately, this pull request went in almost four years ago. Would you be able to share which version number of Terminal you have installed? I ask only because we just (two weeks ago) rolled out a fix for an API version change the Cloud Shell team published... which if you don't have could certainly be why you're hitting this error again. |
Oh, wow! This complicates things. I suspect you’re on Terminal 1.12 because you are on a version of Windows that has gone out of support. We’ll look at the cost of bringing the new Azure Cloud Shell API version back to 1.12. For reference, the current version is 1.20. It’s about two years newer than what you have. :/ |
I'll submit a ticket with scalable and refer to this thread to see if they
can update the terminal version.
…On Mon, May 13, 2024, 22:50 Dustin L. Howett ***@***.***> wrote:
Oh, wow! This complicates things. I suspect you’re on Terminal 1.12
because you are on a version of Windows that has gone out of support.
We’ll look at the cost of bringing the new Azure Cloud Shell API version
back to 1.12.
For reference, the current version is 1.20. It’s about two years newer
than what you have. :/
—
Reply to this email directly, view it on GitHub
<#8197 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAB2ZFN63A3PHPUGJ2GQMMLZCF3XVAVCNFSM4TOMZPNKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMJQHEYTONRZGQYQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Fallback to powershell if "preferred shell" is not specified in the user
settings of Azure CLI.
I am still not sure what is the full set of scenarios that the problem
might occur, but for me it occurred for an "old" cloud shell account,
and didn't reproduce since I have reconfigured it. These behavior might
be explained by the fact that "preferred shell type" did not exist in
the API originally and thus was not set. In such case, Terminal
succeeds to retrieve to the settings but then crashes when reading the
missing field. To fix it, I handle the case where the field is missing
and fallback to powershell
Validation Steps Performed
Closes #7056