Missed CancellationToken for QueryAsync with an arbitrary number of input types

[Dardjiling]

In methods QueryAsync with an arbitrary number of input types missed CancellationToken. In this methods initialized CommandDefinition with default(CancellationToken). CancellationToken should be moved to method parameters.

https://github.com/StackExchange/Dapper/blob/82a005953573b00b1d4c39e43568fb45449dd8e4/Dapper/SqlMapper.Async.cs#L974

[AndreaCuneo]

We're experiencing the same problem. Would be better to add an overload that takes a CommandDefinition instead of sql string, as the rest of methods, but with the Type[]

[NickCraver]

We're racking up items for the 2.0 timeframe...adding cancellation tokens everywhere will be included. We have another big project in the pipe first (porting Stack Overflow to .NET Core), so I don't have a timeline. I just wanted to say: yes, this is planned.

[mentadev]

Great, I'll be waiting for this change I need to add the cancellationToken to the queries so all the processes end smoothly.

[tb-mtg]

Any progress on this issue?

It would help with this SqlKata issue: https://github.com/sqlkata/querybuilder/issues/302

[baleeds]

@NickCraver would you be willing to accept a PR with this change? If so, could we discuss what you had in mind?

[kevin-in-code]

@NickCraver would you be willing to take a quick look at my PR? It is a small non-breaking change that I think will resolve this issue satisfactorily for the community.

[supertx2]

Any progress on this?

[STRATZ-Ken]

@NickCraver I second this. Desperately needed.

[WashingtonARamos]

I'm surprised this is a 4 years old problem, I've also been having this same problem. I don't think it would be much of a hassle to implement a solution, are the contributors willing to accept a pull request for this? If I understood correctly, it's a matter of adding CancellationToken to the methods here:

https://github.com/DapperLib/Dapper/blob/a31dfd3dd4d7f3f2580bd33c877199d7ef3e3ef9/Dapper/SqlMapper.Async.cs#L25

Instead of passing default to the CommandDefinition, just allow an optional CancellationToken to be passed to the method and pass it forward to the CommandDefinition.

[bkoelman]

I'd love to see this fixed as well. There's an open PR that adds an overload that takes a CommandDefinition. This seems to be sufficient (and non-breaking) because a CommandDefinition already contains a CancellationToken.

[andreamorello93]

any update on this?

[nemanja228]

Is there any roadmap on when this issue would be resolved?

There is already an open PR and apparently a plethora of people who'd be happy to contribute. I understand that the issue is about the breaking change in the binary for the existing consumers. So the question is in which version could this be tackled?

Thanks!