unawaited_futures lint is too aggressive - reports Future.whenComplete

[Hixie]

Consider the following code:

  Future<Transaction> openTransaction() async {
    await _connect();
    if (_currentTransaction != null)
      await _currentTransaction.done;
    Transaction result = new Transaction(this);
    result.done.whenComplete(() {
      _currentTransaction = null;
    });
    return result;
  }

This causes:

   info • Await for future expression statements inside async function bodies. • lib/src/foo.dart:136:5

...but doing what the lint suggests would change the semantics of the code and not be correct.

[zoechi]

does

var _ = result.done.whenComplete(() {

fix the linter warning?

It was clear when this lint was introduced that there are always cases where one doesn't want to await and therefore false positives can't be avoided.
Another always available option is using // ignore: lint_rule to suppress a lint

[Hixie]

oh is the problem that whenComplete returns a Future?

That's one Future that should probably be ignorable... (generally, exceptions from that are like exceptions from a finally, i.e. not expected and it's ok if they end up uncaught and reported by the root zone).

[zoechi]

Not sure. I didn't see where exactly you got the linter warning.

[alexeieleusis]

I have too many open bugs right now :(
I'll assign to the rule author and come back if it is still open once I close the ones I have open, IIUC the code in question is here https://github.com/dart-lang/linter/blob/master/lib/src/rules/unawaited_futures.dart
...
I cannot assign it, so through mention cc @ochafik

[lrhn]

Since this was just linked to, I'll point out that the warning here is reasonable.
The future returned by whenComplete is not awaited. If it completes with an error, that error will be unhandled. That's precisely the kind of potential error the lint is intended to catch

Using unawaited(...) to make that explicit that the missing await is deliberate (and likely that the author considered it and decided that there won't be any errors) seems like the recommended behavior.
(And they can use .ignore() instead of unawaited if there might be an error, but it shouldn't be handled here.)

[bwilkerson]

I think it's fairly clear that this isn't likely to be changed, so I'm going to close it.