@sharwell: it's unclear to me why this actually fixes it. Specifically, what's causing this relationship:

Moving the JTF-aware scheduler down to the EditorFeatures layer causes UseExportProviderAttribute.After to dispatch through JTF instead of trying to dispatch through XUnit's test synchronization context, which doesn't end up running on the WPF dispatcher.

I have a guess, but I'd rather the PR was clear. 😄

More generally, the change in general makes me hesitate too: if I could remove the VisualStudioWorkspace task scheduler without breaking people I'd do so in an instant; us putting this on a UI thread is something we absolutely regret. Moving this to EditorFeatures seems to be doubling down on it, and also could potentially break other hosts that didn't want this. For example, what is the impact here for VS for Mac?

it's unclear to me why this actually fixes it. Specifically, what's causing this relationship:

The default task scheduler prior to this change is obtained here:

For XUnit tests, the current context scheduler becomes AsyncTestSyncContext. Unfortunately, work posted to that synchronization context isn't running like we'd expect when we push a DispatcherFrame here:

There are three primary options for correcting this:

1. Use a custom task scheduler for test code which dispatches through Dispatcher (or through JoinableTaskFactory since that works here too)
2. Use a custom task scheduler for test code which dispatches to TaskScheduler.Default
3. Move VisualStudioTaskSchedulerProvider down to the layer where IThreadingContext is defined, which ensures that all consumers that pull the EditorFeatures layer have a task scheduler which works with the context.

Other applications will either fall into a bucket where the default task scheduler provider worked as-is (and the new one will also work), or they were already using one of the above workarounds.

Ah, so xUnit will wait for work scheduled to the AsyncTestSyncContext, but it does that after our UseExportProviderAttribute.After runs? Even though I'm not a fan of tests being async void, but wouldn't those be broken too, which is why I understand xUnit has the special sync context in the first place?

Other applications will either fall into a bucket where the default task scheduler provider worked as-is (and the new one will also work)

I guess I could totally imagine a host where the Workspace gets created on a background thread, and this is changing behavior now. I guess of your options presented I'd do the first -- move the code down but still leave the exporting explicit for tests and the VS layer. But my earlier question still stands -- something seems more fundamentally off here first.

Although I guess you could argue that if we break a host with this change, they were already on pretty thin ice if they were that sensitive for which thread they were on in the first place. I'm also not sure whether we care about cases where they are MEF importing editor features but don't export IThreadingContext as a host like CodeFlow. I guess your provider would MEF reject, but I'm not sure to what end precisely.

but don't export IThreadingContext

IThreadingContext (and JTF) is required for the EditorFeatures layer, and any host using this layer already supports it. There is no main thread requirement though, and this provider handles both cases.

Note that the service default layer for this service was changed to Editor, so any host providing their own implementation of this service would not be impacted (as it would be using Host).

IThreadingContext (and JTF) is required for the EditorFeatures layer, and any host using this layer already supports it.

You're right, since at this point even the editor itself more or less requires it. Not sure what I was thinking there.

So I agree this fix doesn't really break anything or change behavior, but my other question is unanswered: if work is being scheduled to AsyncTestSyncContext, why is xUnit not waiting for that prior to running the after test handler? Am I misunderstanding the xUnit design here?

if work is being scheduled to AsyncTestSyncContext, why is xUnit not waiting for that prior to running the after test handler?

If the test method returns Task, it uses that instead of waiting for the synchronization context to report completion.
https://github.com/xunit/xunit/blob/a8614d34999c889e1c8014f679de95d20eae1304/src/xunit.execution/Sdk/Frameworks/Runners/TestInvoker.cs#L257-L271

@sharwell: for defense in depth should we also be updating our code to wait on that as well, or fail the test if there's still pending work to catch other issues like this? I'm also a bit confused then looking at it because it seems AsyncTestSyncContext itself just either runs things to the thread pool or simply pushes them to the underlying context. So:

Unfortunately, work posted to that synchronization context isn't running like we'd expect when we push a DispatcherFrame here:

Makes me wonder what the underlying context was and why it was interfering as well.

@jasonmalinowski The root cause of the test failures was a processing delay for things queued to the main thread with lower priority than a yield operation also running on the main thread. The yield is being fixed by #44514.