Settings can't be reloaded due to threading issues

[Efreak]

Windows Terminal version

1.24.2812.0

Windows build number

10.0.26200.6899

Other Software

Software that has been running when I see the error (usually no more than 2-3 tabs at a time):

• CMD.exe (ie, just a blank terminal left open)
• koboldcpp (running up to 4 small LLMs ranging from pythia 70m to llama 1b, a total of 3.88gb right now)
• random programs that I happen to have left running (some dotnet dlls, calibre with debugger attached, some python/nodejs scripts, etc)
• WSL2 environments
• SSH connections (usually they're disconnected by the time I sit down)
• cygwin bash shell

Steps to reproduce

Leave Windows Terminal running overnight. The error pops up on its own.

Expected Behavior

No errors without user input.
No reloading the settings file when it hasn't even changed (unless this is coming from before then?)

Actual Behavior

A window pops up with An outgoing call cannot be made since the application is dispatching an input-synchronous call.

---

Screenshot:

[Efreak]

Note: This is currently also happening when I open a new instance of the terminal (either opening a new window from the start menu, or dragging an existing tab out of its window, even if it's the only tab in that window)

[codefox42]

I have also been seeing this message on several computers since at least October 20. I couldn't recognize a pattern yet, but leaving the terminal window open overnight would at least suit my situation.

[lhecker]

The yellow error message is quite helpful though. It's probably related to this then?

terminal/src/cascadia/TerminalSettingsModel/CascadiaSettingsSerialization.cpp

Lines 72 to 92 in 5ae95d7

	// Function Description:
	// - Extracting the value from an async task (like talking to the app catalog) when we are on the
	// UI thread causes C++/WinRT to complain quite loudly (and halt execution!)
	// This templated function extracts the result from a task with chicanery.
	template<typename TTask>
	static auto extractValueFromTaskWithoutMainThreadAwait(TTask&& task) -> decltype(task.get())
	{
	std::optional<decltype(task.get())> finalVal;
	til::latch latch{ 1 };
	const auto _ = [&]() -> safe_void_coroutine {
	const auto cleanup = wil::scope_exit([&]() {
	latch.count_down();
	});
	co_await winrt::resume_background();
	finalVal.emplace(co_await task);
	}();
	latch.wait();
	return finalVal.value();
	}

I wonder if we need to make the entire settings loading an async function...

[DHowett]

Huh. I don't know why that would have changed, though?

[lhecker]

Yeah, we have several new bugs that I'm not sure where they're coming from (e.g. the jumping scroll one, or the one with the trackpad). This one as well, shouldn't be affected by the windowing refactor, I think?

It's a long shot, but the only thing I can imagine what causes this is that previously we'd reload settings on a thread that's not a UI thread (it was the main()-thread for WindowEmperor).

[neo254155-creator]

Hi! I'd love to work on this issue. Could you please assign it to me?