Problem

The application-thread eviction assist loop (__wti_evict_app_assist_worker in evict_dispatch.c) has a per-call cap intended to bound how much eviction work a single calling thread absorbs, independent of the trigger check:

if (!__wt_evict_needed(session, busy, readonly, true, &pct_full) ||
{{ (pct_full < 100.0 &&}}
{{ (evict->eviction_progress > initial_progress + max_progress)))}}
{{ break;}}

with max_progress set to 5 for a busy caller, 20 otherwise.

The pct_full < 100.0 guard can never be true while the loop is running. _wt_evict_needed computes pct_full = 100 - min(margins) across the clean/dirty/updates triggers (evict_inline.h), and can only return true when at least one margin is negative — which forces pct_full >= 100 by construction. The loop only continues while _wt_evict_needed is true, so for every iteration where the progress check is evaluated, pct_full is already >= 100. The progress-cap branch is therefore unreachable: the only way the loop exits is via the trigger no longer being exceeded, an operation timeout, or (since WT-18210) the bounded-wait check at transaction resolution.

Impact

No functional bug on its own — the loop still terminates via other paths. But it means WiredTiger has never actually capped how many pages a single application thread will evict while the cache remains over trigger, despite the code appearing to implement exactly that cap. This was found while investigating SERVER-132391 (WT-18210): a working progress cap might have independently bounded a stuck thread before the transaction-resolution-specific fix was needed.

Fix

Either:

• Make the cap reachable — track the calling thread's own contribution to eviction_progress correctly and drop the pct_full < 100.0 condition (or replace it with the correct intent, if any), or
• Remove the dead branch entirely if a per-call progress cap is no longer wanted, given WT-18210 now bounds the transaction-resolution case by time instead.

A Catch2 test exercising __wt_evict_needed across the clean/dirty/updates trigger matrix (busy and not-busy) should assert pct_full >= 100.0 whenever it returns true, both to document the current dead condition and to regression-test whichever fix is chosen.

Out of scope

Does not change WT-18210's bounded-wait fix. This is a latent, independently-dead code path, not a cause of the SERVER-132391 deadlock.