This rule allows/disallows returned promises to be awaited. It doesn't say anything about non-returned promises. Why would you want this code to be flagged, anyway?

Josh is correct - this rule doesn't enforce a promise is returned only that a returned promise is or isn't awaited. Closing as working as intended.

Feel free to continue discussing though and we can reopen if required.

@bradzacher,

Fair enough that I misinterpreted what this rule was supposed to do, but I keep reading and re-reading the documentation, and I'm not convinced it actually says what this rule does.

What is says it does:

Enforce consistent returning of awaited values.

What it actually does:

Enforce consistent awaiting of returned values.

Wordier but more complete version:

Enforce whether a returned promise is always awaited, never awaited, or awaited when inside a try/catch.

The reason I thought I wanted it to actually return the awaited value is to enable better stack traces, but I acknowledge I don't quite get the exact circumstances under which it's necessary to return the awaited expression to attain that benefit. It would be nice if the documentation made the stack trace behavior for the different options of this rule crystal clear, as it's difficult to really make an intelligent decision about this rule's options without this knowledge.

For what it's worth, my codebase currently uses return await for getters/queries and just await for setters/mutations.

The wording in the docs is a bit cumbersome - happy to accept a PR if you think you can improve the docs.

@bradzacher, my previous comment is a pretty good preview of how I think the docs could be improved. I'm happy to work on a pull request, but I would appreciate some feedback on the two different wording options I offered as well as some help with my question about stack trace behavior