Debug resolving can only happen once, resulting in missed actions

[bwateratmsft]

In VSCode's implementation of DebugConfigurationProviders, resolveDebugConfiguration will only be called for the first provider. If a provider resolves into another--for example, this is how the Docker extension handles .NET and Python debugging--then the resolvers for the other are never called.

In the case of the Docker extension, we have a debug configuration type of docker. Depending on platform, this will resolve into coreclr (.NET), node (Node.js), or python (Python of course). Each of these supports some form of remote debugging which is how container debugging is done, but all are different, so they each need special platform-specific code in the Docker extension to resolve.

In the case of Python, we run our Docker-specific resolving code, and then there is additional code we expected the Python resolver to run--however, the Python resolver never gets called. Instead, it is handed directly to the Python debug adapter. As a result, there isn't a great way to fix microsoft/vscode-docker#2455. The options are to either duplicate the logic that the Python resolver is doing, or otherwise ignore some user configuration in order to do it more simply. Neither is really ideal. What we'd prefer is for the Docker DebugConfigurationProvider to resolve the configuration into a python one, and then the Python DebugConfigurationProvider would also have a chance to run. I'm not entirely sure how VSCode would decide that it is done--perhaps if the type does not change between start and end of the resolve call--but there must be some way.

@int19h FYI

[int19h]

This applies to both resolveDebugConfiguration and resolveDebugConfigurationWithSubstitutedVariables - we utilize both.

More broadly speaking, the problem is that the resolvers are only picked once based on the initial value of "type", but then the debug adapter factory is picked based on the final value. Thus, it's possible to get a config in the factory for a given type that has not passed through the corresponding resolver. If the factory relies on something done by the resolver, things break. We've always been assuming that if the extension registers both resolver and factory for the same type, they're always guaranteed to be called in order; not sure if the actual behavior is intentional, or changing "type" was not anticipated; note, though, that the docs don't place any constraints on how the resolver can change the config.

[ooeygui]

We are encountering this as well - it seems like there is a conflict where our debug resolver does not get called. Uninstalling other extensions causes it to work again. It started working when we uninstalled the docker extension. Given this thread, I'm not sure it is just the docker extension causing issues. I'd be happy to help investigate.

[jkoritzinsky]

I have a fix for this in #143054 just waiting for someone to review.

[connor4312]

Thanks for the ping, looking at that