`FileFinder._find_children` can loop forever on a persistently failing directory scan

• Location: Lib/importlib/_bootstrap_external.py:1469 (inside a while True: loop, backing the new PathEntryFinder.discover() API, added 2026 via gh-139899)

https://github.com/python/cpython/blob/1ad63ccc066a329180cfa8f4a8c4be8be47db973/Lib/importlib/_bootstrap_external.py#L1452-L1472

• Problem: Scans a directory via os.scandir(); any OSError from next() or from an entry's is_dir()/is_file() is caught and ignored without breaking the loop. For a transient single-entry failure this is reasonable (skip and continue). But if the underlying condition is persistent — e.g. an NFS "stale file handle," a disconnected removable volume — every subsequent next() raises the same error forever, and the loop never terminates: no break, no retry limit.
• Reproducer (verified): patched os.scandir to return an iterator whose __next__ unconditionally raises OSError forever; finder._find_children() under a 10-second timeout was killed (exit 124) — confirmed genuine hang. A companion test with a single transient injected error correctly skipped it and returned all real entries, confirming the "skip one bad entry" case works — it's specifically the persistent-failure case that hangs.
• Suggested fix: Add a break (or a bounded retry counter) in the except OSError: branch.
• Difficulty: Small, but a real hang bug (not just silent data loss) — worth flagging prominently. New code (2026), no existing discussion found.

CPython versions tested on:

CPython main branch

Operating systems tested on:

Linux

Linked PRs

• gh-155939

Start in Lib/importlib/_bootstrap_external.py around line 1469, inside FileFinder._find_children’s scan loop. Run the persistent-failure reproducer and the transient-error companion test described in the issue. Done means persistent OSError scanning terminates while a single transient entry failure still allows the remaining entries to be returned.