In Selenium, why can a FluentWait with pollingEvery(Duration.ofSeconds(2)) check its condition less often than every two seconds?

## What pollingEvery actually sets `pollingEvery(Duration)` on Selenium's `FluentWait` sets **how long the thread sleeps after an attempt that did not succeed**. It is not a scheduler, not a metronome and not a background timer. The loop inside `until()` is deliberately simple: 1. apply the function to the input — for browser waits, the `WebDriver`; 2. if the result is neither `null` nor `Boolean.FALSE`, return it and stop; 3. if the deadline has passed, throw `TimeoutException`; 4. otherwise sleep for the configured interval, then go back to step 1. The sleep in step 4 is the only thing the interval controls. Whatever the function itself costs is spent **on top of** it. Selenium's own documentation on `pollingEvery` says exactly that: in reality the interval may be greater, because the cost of evaluating the condition function is not factored in. ## Why the real gap is bigger than the number you passed The effective period between attempts is roughly **evaluation time + interval**, and evaluation is rarely free: - every `findElement` inside the condition is a **round trip to the remote end** — a real HTTP request to the driver and back; - the expensive case is a condition that has to *fail* to find something, because the remote end does the full lookup before answering; - an `executeScript` call that asks the page whether the quote has settled is another round trip, plus however long the script runs; - a remote Grid puts network latency on every one of those round trips; - a condition that touches several elements pays the round trip once per element. Concretely, on a rooftop-solar quote builder whose condition reads the panel count and the annual-yield figure and compares them, an attempt might cost 900 ms. With `pollingEvery(Duration.ofSeconds(2))` you get an attempt roughly every 2.9 seconds, so a 20-second timeout buys about seven attempts, not ten. | | What you configure | What actually happens | |---|---|---| | Gap between attempt starts | the interval you passed | interval **plus** evaluation time | | Attempts inside a timeout | timeout / interval | fewer, and not a round number | | Cost of a slow condition | invisible in the config | charged once per attempt | | Reported in the failure text | the configured interval | the configured interval, never the observed one | ## The deadline is checked after an attempt, never during one The order in step 2 to step 3 above matters. `FluentWait` evaluates first and compares the clock afterwards, and the source carries a comment saying why: so that a condition given a **zero timeout can still succeed**. Two consequences follow: - The condition is always evaluated **at least once**, however small the timeout. - The wait can **overrun** its timeout by up to one evaluation. A condition that takes three seconds, started at 9.5 seconds into a 10-second wait, still runs to completion; `until()` returns or throws at about 12.5 seconds. There is no cancellation. `until()` never interrupts an attempt that is already running, so a condition that blocks — on a page-load timeout, say, or a script that never returns — blocks the whole wait past its deadline. The only interruption `FluentWait` handles is an interrupt of the **sleep**, and it responds by restoring the thread's interrupt flag and throwing `WebDriverException`. ## What the failure message tells you, and what it does not The `TimeoutException` text ends with `(tried for 20 seconds with 2000 milliseconds interval)`. Both of those numbers are the values you **configured**. Nothing in the message reports how many attempts actually ran or how long each one took, so drift between the configured cadence and the real one is invisible in the failure alone. If you need it, time the condition yourself or read the driver's own log of requests. ## Where the sleeping and the clock come from `FluentWait` does not call `Thread.sleep` directly. It holds a `Sleeper` and a `java.time.Clock`, both supplied by the constructor: - the one-argument constructor uses `Clock.systemDefaultZone()` and `Sleeper.SYSTEM_SLEEPER`, which is a lambda over `Thread.sleep`; - the three-argument constructor `FluentWait(T input, Clock clock, Sleeper sleeper)` lets a unit test inject a fake clock and a no-op sleeper, which is how Selenium tests its own wait without spending real seconds. That is also the seam to reach for when you want to prove a wait's behaviour in a unit test rather than against a live browser.