"await" should not be used redundantly for bot framewor

[Tamas_Hegedus1 (Tamás Hegedűs)]

Hi Tibor, (cannot @ mention you), return await is not redundant, and removing await causes undesired side-effects, and in many cases, broken code. I am linking some examples, but in short: not awaiting breaks stack traces, try-catch and try-finally blocks.

So I think the rule is actually harmful, I see more and more people breaking otherwise perfectly fine code by “optimizing” (removing) the await, and some of them were pointing to this particular sonar rule. Would it be possible to remove the rule, or at least deprecate it and extend the documentation to have a big warning about try-catch and try-finally blocks?

Examples:

Difference between `return await promise` and `return promise`

Why no-return-await vs const x = await?

Cross-references, similar threads:

"await" should not be used redundantly

Wow, it is an old thread! May I suggest removing RSPEC-4326 entirely or marking it as a deprecated rule? I think that the industry is slowly arriving at the conclusion that this rule is actually harmful. The performance benefit claims are shown to be actually false, it is slower when you omit that await None of the IDE-s (or the developers for that matter) are checking if there is a return asyncFn() when wrapping the code in try-catch-finally - so the code is going to be broken The documenta…

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

Hi, 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. Thanks!

TypeScript static code analysis