Imported WSL instance not discovered until Terminal is restarted

[timblaktu]

Windows Terminal version

Windows Terminal Preview Version: 1.21.1272.0

Windows build number

10.0.22631.0

Other Software

PS C:\Users\timbl> wsl.exe --version
WSL version: 2.1.5.0
Kernel version: 5.15.146.1-2
WSLg version: 1.0.60
MSRDC version: 1.2.5105
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22631.3593

Steps to reproduce

1. Export a WSL2 machine as a .tar.gz. As in #17262, I'm doing this with nixos-wsl's tarball builder.
2. Import it: wsl.exe --import <machine-name> %USERPROFILE%\nixos-wsl-tarballs\<machine-name> <path-to-the-wsl-machine-archive.tar.gz-file>
3. In Terminal, click v and see it is not possible to open the new wsl machine's profile.
4. Restart Terminal, and see that the new wsl machine's profile is available and functional.

Expected Behavior

Step 4. above should not be required. In 3, after importing the wsl machine, it should be possible to open it without restarting Terminal.

I would understand if this behavior is "as-designed" and therefore this converted to a feature request.

Actual Behavior

See #Steps To Reproduce.

[zcobol]

@timblaktu after importing the wsl machine, it should be possible to open it without restarting Terminal and it is! Just not from the drop-down menu. Run wsl -d your_new_distro inside the terminal w/out restarting it.

[lhecker]

I would understand if this behavior is "as-designed" and therefore this converted to a feature request.

This is indeed currently as-designed. Finding new profiles is not super expensive, but it's definitely not cheap, so we can't do it every time that menu is opened. In the past we had considered reworking how profiles are generated: Instead of them being automatically added on startup, we'd just offer them in the settings tab. If we did that we could just refresh the list whenever the settings are opened.

[zcobol]

@lhecker please add a command to refresh the profiles instead of triggering a reload every time I click on the dropdown menu.

[zadjii-msft]

Another terrible thought I just had -

what if we had like, a singular well-known filepath that we don't actually read from, but just listen to for modifications. Then, regardless of which branding / packaging you're on, if an extension source (in this case, WSL) makes changes to the list of profiles, they can touch that file, and cause all terminals to reload their settings.

[zadjii-msft]

Okay so discussion notes:

• What if dynamic profiles weren't generated as whole stub profiles, but as "tasks" / "workflows" / whatever the non-appearance half of a profile is. The thing Dustin's been talking about for years.
• We could generate those freely when the SUI is opened.
• Then the new tab menu would never be updated automatically for new dynamic profiles
• but you could easily add a new profile with that "task"
• and we wouldn't need to store the generated & deleted GUIDs in state.json
• and you could get a little list item with "there are 3 new tasks" in the dropdown or something