`expect.poll(.., { timeout })` doesn't fail early on given `timeout`

[hi-ogawa]

Describe the bug

expect.poll doesn't seem to have timeout race with poll function, or timeout option has issues. For the examples below, I'd expect test to fail in ~100ms instead of failing undefined !== 1 at ~2000ms

import { test, expect } from 'vitest';

test('why 2000', async () => {
  await expect
    .poll(
      async () => {
        await new Promise((r) => setTimeout(r, 1000));
      },
      { timeout: 100 }
    )
    .toBe(1);
});

test('stuck', async () => {
  await expect
    .poll(
      async () => {
        await new Promise((r) => setTimeout(r, 10000));
      },
      { timeout: 100 }
    )
    .toBe(1);
});

❯ vitest run

 RUN  v4.1.0-beta.6 /home/projects/vitest-dev-vitest-667kxr24

 ❯ test/repro.test.ts (2 tests | 2 failed) 7096ms
   × why 2000 2075ms
   × stuck 5019ms

⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯ Failed Tests 2 ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯

 FAIL  test/repro.test.ts > why 2000
AssertionError: expected undefined to be 1 // Object.is equality

- Expected:
1

+ Received:
undefined

 ❯ test/repro.test.ts:11:6
      9|       { timeout: 100 }
     10|     )
     11|     .toBe(1);
       |      ^
     12| });
     13|
 ❯ new Promise ../../../blitz.056788dd.js:31:28254
 ❯ new Promise ../../../blitz.056788dd.js:31:28254

Caused by: Error: Matcher did not succeed in time.
 ❯ test/repro.test.ts:4:3

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

 FAIL  test/repro.test.ts > stuck
Error: Test timed out in 5000ms.
If this is a long-running test, pass a timeout value as the last argument or configure it globally with "testTimeout".
 ❯ test/repro.test.ts:14:1
     12| });
     13|
     14| test('stuck', async () => {
       | ^
     15|   await expect
     16|     .poll(

⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯[2/2]⎯


 Test Files  1 failed (1)
      Tests  2 failed (2)
   Start at  19:10:09
   Duration  7.70s (transform 41ms, setup 0ms, import 55ms, tests 7.10s, environment 0ms)

Reproduction

https://stackblitz.com/edit/vitest-dev-vitest-667kxr24?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:
    vite: latest => 7.3.1 
    vitest: beta => 4.1.0-beta.6

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.

[macarie]

Tangentially related, but would it make sense to provide an AbortSignal as a parameter to the function since the result would be ignored anyway?

[hi-ogawa]

AbortSignal makes sense to me. expect.poll(({ signal }) => ...) looks ergonomic.

[hi-ogawa]

So, #7152 relies on the currently behavior of calling one last polling function after timeout.

vitest/packages/browser/src/client/tester/expect-element.ts

Lines 38 to 53 in 59b0e64

	// element selector uses prettyDOM under the hood, which is an expensive call
	// that should not be called on each failed locator attempt to avoid memory leak:
	// https://github.com/vitest-dev/vitest/issues/7139
	const isLastPollAttempt = chai.util.flag(this, '_isLastPollAttempt')
	if (isLastPollAttempt) {
	return elementOrLocator.element()
	}
	const result = elementOrLocator.query()
	if (!result) {
	throw new Error(`Cannot find element with locator: ${JSON.stringify(elementOrLocator)}`)
	}
	return result

I think locator element error side should also find a new idea to make this idea work.
(This looks like only an independent "smell" and still fixable user-facing timeout behavior separately)