Possible bug in beta5 System.CommandLine API

[vsfeedback]

This issue has been moved from a ticket on Developer Community.

---

[severity:It’s more difficult to complete my work]
There is a Command.SetAction that takes a Func<ParseResult, Task>. I believe this should be Func<ParseResult, Task<int>>.

When converting from the old API, I ended up with an function that returns a Task<int>. This was silently passed to the Func<ParseResult, Task> version, which silently ate the return value and returned 0 instead.

Workaround: Use the override that also takes a cancellation token.

If you want to keep the Func<ParseResult, Task> version, that’s fine, as long as you also add a Func<ParseResult, Task<int>>. When this issue bit me during conversion from the old to the new API, it took some debugging to get to the bottom of.

Aside from that, the new API is a distinct improvement over the old one.

---

Original Comments

Feedback Bot on 7/4/2025, 04:24 AM:

We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.

[mikechristiansenvae]

Edit: Nevermind, I see that it only works if you accept the cancellation token!

You can use an explicit return type

command.SetAction(async static Task<int> (parseResult, cancellationToken) =>
    {
        // Do your stuff
    }
);

[petterh]

I added a PR to address this issue.