'“await” should not be used redundantly' affecting stacktraces

Using dotnet-sonarscanner 5.2.1

This follows up on "await" should not be used redundantly with a different argument. And that is that this suggestion affects generated stack traces, and if anything, I would prefer if the rule suggested it the other way around.

Take for example the following:

async function throwing() {
  await await new Promise(accept => setTimeout(accept, 0));
  throw new Error("test");
async function supposedlyBad() {
  return await throwing();
async function supposedlyGood() {
  return throwing();

When calling supposedlyBad, this is the stacktrace:

Uncaught (in promise) Error: test
    at throwing (<anonymous>:3:9)
    at async supposedlyBad (<anonymous>:6:10)

However for supposedlyGood, you get this:

Uncaught (in promise) Error: test
    at throwing (<anonymous>:3:9)

Suddenly you’re missing the function, as it’s no longer part of the awaited execution flow. Similarly, a breakpoint will skip over it. Is this a known and intended effect of the rule?


This rule is uses ESLint implementation (no-return-await - Rules - ESLint - Pluggable JavaScript linter) and indeed it’s mentioned there that one should not use the rule if one wants the function to appear in the stacktrace.
So I believe we rushed to include this rule in the default profile. Here is a ticket to update rule description and remove it from default profile Remove S4326 from default profile and improve its description · Issue #2674 · SonarSource/SonarJS · GitHub.


1 Like

Thanks for following up on it!

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.