VS Code - Confirm that CodeActionsHandler still does the right thing

[winstliu]

Describe the bug:
In dotnet/vscode-csharp#4988, I updated the CodeActionProvider class to return CodeActions (as per the name!) instead of legacy Commands. Now, I think that Razor's code action handling is dependent on the old Command behavior, assuming that it gets the code actions from omnisharp-vscode:
https://github.com/dotnet/razor-tooling/blob/56a1e44ce929406cf5d96a118c69f258c038390f/src/Razor/src/Microsoft.AspNetCore.Razor.VSCode/src/CodeActions/CodeActionsHandler.ts#L48-L51

The good news is that it turns out codeAction.title === codeAction.command.title, so even though the type returned by the command is different, things should still work. In theory.

However, even though I see CodeActions being returned by vscode.executeCodeActionProvider, they aren't showing up in VS Code. Is that a known issue or am I missing something? (I'm running all of this in a Codespace, so I wouldn't be surprised if messed something up.)

Basically,

1. If I can get confirmation that CodeActionsHandler is dependent on omnisharp-vscode's CodeActionProvider (and it seems like it is because I'm getting CodeActions back, not Commands), I can submit a PR to update the types.
2. Everything else I wrote is just me wondering if code actions are supposed to be working or not.

Version used:
VS Code, C# 1.24.0.

To reproduce:
Steps to reproduce the behavior:

1. Add a console.log after line 51 and observe that you're receiving CodeActions instead of Commands.
2. Write something that should clearly give you code actions, like private List<int> test; in a nullable context.

Expected behavior: Typings to match, and to get code actions.

Actual behavior: Neither :'(

Additional context:
N/A

[NTaylorMullen]

@50Wliu do you see the same issue happen for english versions? As you mentioned there's the "title" check but that of course fails gloriously in non-english scenarios 😆

[winstliu]

Yep, unfortunately :/.

I didn't even consider localization as a possible culprit ^^, good to rule that out.

[NTaylorMullen]

Thanks for clarifying! So in that case it's not entirely known or not known. We've been overhauling the Razor language server recently and have unintentionally broken a few VSCode scenarios (this seems like one of them). That being said it is on our roadmap to get language server updates flowing to VSCode again once the dust settles (don't want to do an update with non-concrete bits). I'll mark this as bug and keep it on our radar for when things become more stable