`await expect.poll + finally` fails by "not awaited" detection

[hi-ogawa]

Describe the bug

import { test, expect } from 'vitest';

test('repro', async () => {
  await expect
    .poll(() => 0)
    .toBe(0)
    .finally(() => {
      console.log('poll-finally!');
    });
});

❯ vitest

 DEV  v4.1.0-beta.4 /home/projects/vitest-dev-vitest-kwmkvegw

stdout | test/repro.test.ts > repro
poll-finally!

 ❯ test/repro.test.ts (1 test | 1 failed) 7ms
   × repro 5ms

⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯ Failed Tests 1 ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯

 FAIL  test/repro.test.ts > repro
Error: expect.poll(assertion).toBe() was not awaited. This assertion is asynchronous and must be awaited; otherwise, it is not executed to avoid unhandled rejections:

await expect.poll(assertion).toBe()

 ❯ test/repro.test.ts:6:6
      4|   await expect
      5|     .poll(() => 0)
      6|     .toBe(0)
       |      ^
      7|     .finally(() => {
      8|       console.log('poll-finally!');
 ❯ new Promise ../../../blitz.508a1324.js:31:28071

⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯[1/1]⎯


 Test Files  1 failed (1)
      Tests  1 failed (1)
   Start at  18:47:34
   Duration  827ms (transform 270ms, setup 0ms, import 293ms, tests 7ms, environment 0ms)

 FAIL  Tests failed. Watching for file changes...
       press h to show help, press q to quit

Reproduction

https://stackblitz.com/edit/vitest-dev-vitest-kwmkvegw?file=test%2Frepro.test.ts

System Info

System:
    OS: Linux 5.0 undefined
    CPU: (8) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
    Memory: 0 Bytes / 0 Bytes
    Shell: 1.0 - /bin/jsh
  Binaries:
    Node: 20.19.1 - /usr/local/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 10.8.2 - /usr/local/bin/npm
    pnpm: 8.15.6 - /usr/local/bin/pnpm
  npmPackages:
    vitest: beta => 4.1.0-beta.4

Used Package Manager

npm

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[sheremet-va]

What’s the use case for this?

[hi-ogawa]

It was for quick debugging where I had

await expect.poll(() => serverLogs).toContain('hmr update')

but, toContain error message only shows AssertionError: expected [ …(4) ] to include 'hmr update', so my quick instinct was to do this:

await expect.poll(() => serverLogs).toContain('hmr update').finallay(() => console.log(serverLogs))

which failed by "not awaited" error. I soon changed to onTestFailed(() => console.log(serverLogs)), but bringing onTestFailed was less quick than .finally(() => console.log(...)).

[sheremet-va]

I think this is just a caveat we have to live with for a better general DX, like the Promise.all example.

With the current check we want people to force the use of await expect since it calls then automatically, and we can't validate if promise after finally was awaited. Obviously, it's also possible to bypass it by calling then manually, but that would be conscious, while finally is more likely to be accidental (I think)

We could always just add the resolved variable to finally/catch also, but then it means the user manually called them, which sounds weird to me, but maybe there are use cases? (like yours)

[hi-ogawa]

Right, I remembered the limitation, but I think catch/finally + await is false-positive detection of proper promise usage and making the test fails doesn't feel right. I'd vote for letting catch/finally set resolved, so effectively treating it as opting-out from async enforcement.