[JackyHsu-X]

Warning

This PR was written autonomously by an AI agent and has not been reviewed
by a human yet. Maintainers should ignore it until the human author has reviewed,
understood, and approved everything that the AI agent wrote.

as_completed.count() counts distinct pending futures, although the iterator returns every occurrence of repeated futures. For example, as_completed([x, x, y]).count() reports 2 before the tracking callbacks run, while iteration produces three entries. This makes the reported outstanding count depend on whether tracking has moved results into the queue.

Sum the stored occurrence counts for pending futures. Keep the existing queue count and locking. Add local-cluster regression tests covering duplicate inputs, add(), update(), both with_results modes, and the remaining count after each yielded result.

There is no existing issue to close.

• Tests added / passed
• Passes pixi run lint

Validation and AI assistance

Prepared with OpenAI Codex.

Windows, CPython 3.13.15, Dask 2026.8.0:

• Both regression cases fail against unmodified upstream (assert 2 == 3).
• python -m pytest distributed/tests/test_as_completed.py -q: 22 passed, using real local scheduler and workers.
• Ruff 0.15.16 (the upstream hook version) check and format check pass for both changed files.
• git diff --check: passed.

pixi run lint, the full repository suite, and other OS/Python versions were not run. Official pre-commit hooks on both changed files passed, including Ruff and mypy (codespell had no matching files). The complete target suite also passed with thread/process leak checks and coverage enabled (22 passed); the changed counting line was exercised.

AI self-review: At the author's explicit request, Codex reviewed the complete diff and this description again, found no blocking issues, and reran both regression cases (2 passed). The author requested marking this PR ready after that AI review. No human code review is claimed. The pending-count calculation now takes time linear in the number of distinct pending futures; this avoids adding separate counter state. Hosted CI is still in progress.

[github-actions]

Unit Test Results

See test report for an extended history of previous test failures. This is useful for diagnosing flaky tests.

    40 files  ± 0      40 suites  ±0   14h 27m 36s ⏱️ + 34m 42s
 4 162 tests + 2   3 978 ✅  -  1    178 💤 ±0  6 ❌ +3 
81 000 runs  +39  76 755 ✅ +38  4 239 💤  - 2  6 ❌ +3 

For more details on these failures, see this check.

Results for commit 38976db. ± Comparison against base commit dc182bd.

[JackyHsu-X]

Automated CI investigation by Codex, at the submitter's request. No source changes are proposed here.

The eight failing execution jobs fall into these groups:

• Both nightly jobs abort collection because bokeh.models.Arrow cannot be imported. The same error occurs on the PR's base commit dc182bda54af488d029f2c40db0893d5f48e69d5 in the earlier main-branch nightly run 39883664690, before this PR was opened. Tests do not execute in those jobs.
• Jupyter test_shutdowns_cleanly times out in ARM py311 and upstream py314. The same test/connect-timeout signature also occurs independently on main at the same base in job 121423360606.
• Windows py311 times out in test_closed_input_only_worker_during_transfer. Earlier main at the same base also times out in that test, e.g. job 115455608522, on Windows py310.
• The mindeps-dataframe JUnit artifact reports TLS test_basic with a closed stream, and TLS functional test_nanny timing out during cluster creation. Earlier same-base main shows the same TLS CLI case/error in job 119391860910 and the same TLS functional nanny/cluster-creation timeout in job 116016059311.
• macOS py314 test_map passes a negative remaining timeout to Future.result, producing ValueError: could not convert string to float: '1-0.0005288124084472656'. A controlled local clock experiment with real Client/Executor/Future objects reproduces the exact message with both the PR count method and the original base count method restored in memory. The changed as_completed.count method is called zero times. This diagnoses that timeout path; it is not a macOS CI reproduction.
• Ubuntu py311 has [XPASS(strict)] dask/distributed#9184 in test_handle_null_partitions_2: the test unexpectedly passes. Earlier same-base main job 120267582838 records it as the expected XFAIL. I have not reproduced the XPASS transition or changed its marker.

Both new regression cases pass in all six failed jobs that actually execute tests, including the recovered mindeps-dataframe JUnit results. A fresh local Windows/Python 3.13.15 run of the complete test_as_completed.py with thread/process leak checks passes all 22 tests. The aggregate Unit Test Results failure summarizes existing failed executions; CI is still failing.

Could a maintainer please retry the failed regular Tests jobs and the upstream py314 job, and assess the strict XPASS? A regular Tests retry through the submitter's account returned HTTP 403 (Must have admin rights to Repository). The nightly Bokeh collection incompatibility remains separately recorded.