I don't think that there's a bug here - instead it seems to me like you have configured a lint rule to use a style that is fundamentally incompatible with your codebase.

Your application logic explicitly relies on the presence or absence of the await in order to function correctly - so enforcing that you "always return await is incorrect in your codebase.

It's not possible for us (or typescript, for that matter) to detect this sort of implicit interdependency between things.

It's generally very, very, very rare that this sort of code style is used in JS code given that JS is single-threaded. Most of the time codebases will use the promise themselves as the locking signal to avoid the need to maintain an external lock because an external lock is a manual, complicated, error prone thing.

Evidence of the rareness of this pattern is that we have numerous promise rules that auto-fix things and have existed for >5y (eg this rule is 5y old) and this is the first report ever we've seen of someone using a locking system!

Given the rarity of this I'm inclined to close this as a known, rare edge case. Maybe it could be documented as a caution.

thoughts @typescript-eslint/triage-team?

i mean, sure.... the example that I came up with is minimal reproduction of something that wasn't literally a lock in the original issue, but still something that blocked the getUserInput function. Either way, it certainly was in the wild, and the implementing change to fix it would be very quick and easy (and, also, it's already done to be honest, see https://github.com/kirkwaiblinger/typescript-eslint/compare/main...return-await-safer-autofixes?expand=1), so... might as well?

FWIW my perspective is that the error handling control flow aspect of this rule is very much a central concern, since the default config explicitly flags different code based on whether it affects the exception handling control flow. Thanks to that, it's almost a trivial change to use those existing codepaths to decide between autofix or suggestion.

oh, sorry, one thing to clarify

instead it seems to me like you have configured a lint rule to use a style that is fundamentally incompatible with your codebase.

This is a situation where we inherited a codebase that had never been under lint, and had been turning on lots of linter rules and running autofixes on them. So, that particular code was already crappy, should never have been written that way, and, very much correctly was flagged by the linter! I don't think that the codebase was incompatible with the linter or whatever, i think that the linter was finding the crazy skeletons in the closet :) Just, not every skeleton is safe to autofix, despite very much needing to be fixed.

But, I guess, more generally, I really do think it's a no-brainer to update the rule exercise caution with the following completely standard scenario. Maybe it's a better illustration.

async function functionThatHasErrorHandling() {
    try {
        // would autofix to return await thingThatMaybeRejects();
        return thingThatMaybeRejects();
    } catch (error) {
       // This code has never run in the history of the codebase. But the 
       // authors of this codebase clearly don't know that, since, well,
       // they wrote this dead exception handling block in the first place.

       // Why should we assume it's safe for it to do so now,
       // rather than flagging the line with a suggestion (or custom error message)
       // that alerts the programmer that this previously dead codepath will now
       // potentially start to run?

       exec('sudo rm -rf system32');
    } 
}

It would seem there's precedent for this kind of caution, looking at things like https://typescript-eslint.io/rules/prefer-optional-chain/#allowpotentiallyunsafefixesthatmodifythereturntypeiknowwhatimdoing. Only this seems like a stronger case, since it's something that wouldn't be caught by a Typescript error.

I think we need to switch it from a fix to a suggestion. Switching from return promise to return await promise changes the behavior of the code. Although it's almost always better behavior (since it captures the stack better with try semantics), it's still different behavior.

This also occurs with the new using keyword as well.

function getLock() {
  const l = lock();
  return { [Symbol.dispose]: () => l.release() };
}

function foo() {
  using foo = getLock();

  // unlocks as soon as the "sync" code finishes
  return getPromise();
  // unlocks once the promise resolves
  return await getPromise();
}

(ofc this new syntax implicitly uses finally under the hood)

I think we need to switch it from a fix to a suggestion

I'm not sure I agree - the behaviour should be consistent across really every case aside from the finally and catch cases.

Though I disagree that catching in a different location is a dangerous change in behaviour to exercise code paths that were previously unreachable due to a bug.

I'm okay if we add specific handling for the finally case to make that a suggestion, but I don't think other cases need be a suggestion.
My justification is that if it were a problem to have this as a fixer we would have had at least one issue filed over the last 5 years since the rule was added.

I'm in agreement with @JoshuaKGoldberg that it should be a suggestion, even if for most users it doesn't matter. Autofix should not change code behavior in a salient way.

It seems this issue hasn't had any activity for a while and opinions still diverge... 🤔

I still think it seems simplest both conceptually and implementation-wise to posit "wherever the in-try-catch setting requires the use of return await ought to be a suggested fix rather than an autofix", thereby deferring all questions of what constitutes a relevant control flow change to previous work, rather than relitigating them here. (I realize I may have unintentionally opened the door to that in the issue report when my intention was to just demonstrate the value proposition).

@bradzacher I don't mean to push too hard, but would that resolution be acceptable?

Coming back to this: @kirkwaiblinger and I poked at the control flow nuances and it seems pretty reasonable to me that we'd switch any fixer that can change control flow to a suggestion. Marking as accepting PRs with the note that this shouldn't change all fixers to suggestions. Just the ones that modify control flow. 👍