chore(deps-dev): bump pytest from 8.4.2 to 9.0.2

[dependabot]

Bumps pytest from 8.4.2 to 9.0.2.

Release notes

Sourced from pytest's releases.

9.0.2

pytest 9.0.2 (2025-12-06)

Bug fixes

• #13896: The terminal progress feature added in pytest 9.0.0 has been disabled by default, except on Windows, due to compatibility issues with some terminal emulators.

  You may enable it again by passing -p terminalprogress. We may enable it by default again once compatibility improves in the future.

  Additionally, when the environment variable TERM is dumb, the escape codes are no longer emitted, even if the plugin is enabled.

• #13904: Fixed the TOML type of the tmp_path_retention_count settings in the API reference from number to string.

• #13946: The private config.inicfg attribute was changed in a breaking manner in pytest 9.0.0. Due to its usage in the ecosystem, it is now restored to working order using a compatibility shim. It will be deprecated in pytest 9.1 and removed in pytest 10.

• #13965: Fixed quadratic-time behavior when handling unittest subtests in Python 3.10.

Improved documentation

• #4492: The API Reference now contains cross-reference-able documentation of pytest's command-line flags <command-line-flags>.

9.0.1

pytest 9.0.1 (2025-11-12)

Bug fixes

• #13895: Restore support for skipping tests via raise unittest.SkipTest.
• #13896: The terminal progress plugin added in pytest 9.0 is now automatically disabled when iTerm2 is detected, it generated desktop notifications instead of the desired functionality.
• #13904: Fixed the TOML type of the verbosity settings in the API reference from number to string.
• #13910: Fixed UserWarning: Do not expect file_or_dir on some earlier Python 3.12 and 3.13 point versions.

Packaging updates and notes for downstreams

• #13933: The tox configuration has been adjusted to make sure the desired version string can be passed into its package_env through the SETUPTOOLS_SCM_PRETEND_VERSION_FOR_PYTEST environment variable as a part of the release process -- by webknjaz.

Contributor-facing changes

• #13891, #13942: The CI/CD part of the release automation is now capable of creating GitHub Releases without having a Git checkout on disk -- by bluetech and webknjaz.
• #13933: The tox configuration has been adjusted to make sure the desired version string can be passed into its package_env through the SETUPTOOLS_SCM_PRETEND_VERSION_FOR_PYTEST environment variable as a part of the release process -- by webknjaz.

... (truncated)

Commits

• 3d10b51 Prepare release version 9.0.2
• 188750b Merge pull request #14030 from pytest-dev/patchback/backports/9.0.x/1e4b01d1f...
• b7d7bef Merge pull request #14014 from bluetech/compat-note
• bd08e85 Merge pull request #14013 from pytest-dev/patchback/backports/9.0.x/922b60377...
• bc78386 Add CLI options reference documentation (#13930)
• 5a4e398 Fix docs typo (#14005) (#14008)
• d7ae6df Merge pull request #14006 from pytest-dev/maintenance/update-plugin-list-tmpl...
• 556f6a2 pre-commit: fix rst-lint after new release (#13999) (#14001)
• c60fbe6 Fix quadratic-time behavior when handling unittest subtests in Python 3.10 ...
• 73d9b01 Merge pull request #13995 from nicoddemus/patchback/backports/9.0.x/1b5200c0f...
• Additional commits viewable in compare view

You can trigger a rebase of this PR by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Disclaimer: Experimental PR review

Greptile Summary

This PR bumps pytest from 8.4.2 to 9.0.2 (a major version bump) by relaxing the upper bound in pyproject.toml from <9.0 to <10.0. While the pytest upgrade itself is straightforward, the lock file reveals an unintended side-effect: pytest-asyncio is silently downgraded from 1.1.1 to 0.23.3 because pytest-asyncio 1.x appears incompatible with pytest 9.x, causing uv's resolver to fall back to the highest compatible 0.x release.

Key changes:

• pyproject.toml: pytest constraint widened from >=7.4,<9.0 → >=7.4,<10.0
• uv.lock: pytest 8.4.2 → 9.0.2
• uv.lock: pytest-asyncio 1.1.1 → 0.23.3 (unintended regression — ~20 months of releases dropped)
• uv.lock: backports-asyncio-runner 1.2.0 removed (was a transitive dependency of pytest-asyncio 1.1.1 for Python < 3.11)

The project has no asyncio_mode setting in [tool.pytest.ini_options], which will produce FutureWarning deprecation noise with pytest-asyncio 0.23.x. More importantly, the pytest-asyncio constraint in pyproject.toml should be explicitly updated to reflect which version range is actually compatible with pytest 9, rather than letting the resolver silently pick an older version.

Confidence Score: 4/5

Mostly safe to merge, but the silent pytest-asyncio downgrade from 1.1.1 to 0.23.3 should be reviewed and made intentional before landing.

A P1 issue exists: pytest-asyncio is silently downgraded ~20 months due to a resolver conflict with pytest 9.x. This is a dev-only dependency so it won't affect production, but it could silently break async test behaviour or introduce deprecation noise without the team being aware of the root cause. Confirming CI passes and explicitly acknowledging/pinning the pytest-asyncio version would resolve the concern.

uv.lock — specifically the pytest-asyncio version resolution and its interaction with the pytest 9.x constraint.

Important Files Changed

Filename	Overview
pyproject.toml	Upper bound on pytest relaxed from <9.0 to <10.0, allowing the 9.0.2 bump; no other changes
uv.lock	pytest bumped 8.4.2→9.0.2; pytest-asyncio unexpectedly downgraded 1.1.1→0.23.3 due to pytest 9.x incompatibility; backports-asyncio-runner removed

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["pyproject.toml\npytest >=7.4,<10.0\npytest-asyncio >=0.21.1,<1.2.0"] --> B["uv resolver"]
    B --> C["pytest 9.0.2 ✅"]
    B --> D{"pytest-asyncio 1.1.1\ncompatible with pytest 9.x?"}
    D -- "No (requires pytest <9)" --> E["pytest-asyncio 0.23.3 ⚠️\n(latest compatible 0.x)"]
    D -- "Would be preferred" --> F["pytest-asyncio 1.1.1\n(skipped)"]
    E --> G["backports-asyncio-runner\nremoved (was 1.1.1 dep)"]
    E --> H["No asyncio_mode set\n→ FutureWarning in CI"]

Loading

_{Reviews (1): Last reviewed commit: "chore(deps-dev): bump pytest from 8.4.2 ..." | Re-trigger Greptile}

Greptile also left 1 inline comment on this PR.

[greptile-apps]

pytest-asyncio unexpectedly downgraded from 1.1.1 → 0.23.3

As a side-effect of bumping pytest to 9.0.2, the lock file resolves pytest-asyncio from 1.1.1 (released Sep 2025) all the way down to 0.23.3 (released Jan 2024). This happens because pytest-asyncio 1.x appears to carry a dependency constraint that makes it incompatible with pytest 9.x, so uv's resolver falls back to the highest 0.x release that satisfies the >=0.21.1,<1.2.0 bound.

This is a ~20-month regression in pytest-asyncio and brings several potential concerns:

• Deprecation warnings in pytest-asyncio 0.21–0.23 when asyncio_mode is not set in [tool.pytest.ini_options] — the project currently has no asyncio_mode entry, which will produce FutureWarning noise in CI output.
• Any test helpers or fixtures that relied on pytest-asyncio 1.x behaviour (e.g. the reworked event_loop fixture, scoped loop support) will silently regress.
• backports-asyncio-runner (previously a transitive dep for Python < 3.11) is also removed, which is fine given the project requires Python ≥ 3.10, but is worth being aware of.

Suggested action: Update the pyproject.toml constraint to pytest-asyncio>=0.21.1,<0.25 (or whichever latest 0.x release is pytest-9-compatible and verified against the test suite), or investigate whether a newer pytest-asyncio release (e.g. >=1.2.0) adds explicit pytest 9 support, and adjust the upper bound accordingly. Either way, the downgrade should be an explicit, intentional choice rather than a silent resolver artifact.

[claude]

🔴 Upgrading pytest to 9.0.2 caused pytest-asyncio to be downgraded from 1.1.1 to 0.23.3 (released 2024-01-01), because all pytest-asyncio 1.x versions declare pytest<9 as an upper bound. The current pyproject.toml constraint (>=0.21.1,<1.2.0) needs to be updated to allow pytest-asyncio ≥1.3.0, which is the first release to explicitly support pytest 9.x (pytest<10,>=8.2); without this fix the project's 48 async tests across 8 files may fail or behave incorrectly.

Extended reasoning...

What the bug is

When pytest was bumped from 8.4.2 to 9.0.2, the uv resolver also downgraded pytest-asyncio from 1.1.1 to 0.23.3. This is not an isolated coincidence — pytest-asyncio versions 0.24+ through 1.1.1 all declare a pytest<9,>=8.2 upper-bound constraint, making them incompatible with pytest 9.x. The first pytest-asyncio release that explicitly supports pytest 9.x is 1.3.0 (pytest<10,>=8.2). The resolver's only valid choice within the current >=0.21.1,<1.2.0 constraint was to fall back to 0.23.3 — a version released on 2024-01-01, almost two years before pytest 9.0.

The specific constraint that causes the regression

In pyproject.toml:

"pytest-asyncio>=0.21.1,<1.2.0"

This range excludes 1.3.0+, so within it the only pytest-9-compatible version is 0.23.3 (which predates pytest 9 entirely and therefore never added the <9 guard). All versions between 0.24 and 1.1.1 are explicitly blocked.

Why existing safeguards don't catch this

The metadata-level dependency is technically satisfied (0.23.3 says pytest>=7.0.0 with no upper bound), so the resolver succeeds without error. There is no CI gate that checks whether the resolved version of a transitive dependency regressed. The pyproject.toml constraint was written before pytest 9.x existed, so it never anticipated this gap.

Impact

The project has 48 uses of @pytest.mark.asyncio across 8 test files:

• test_decorators.py (10 marks)
• test_propagate_attributes.py (10 marks)
• test_langchain_integration.py (10 marks)
• test_utils.py (7 marks)
• test_openai.py (5 marks)
• test_batch_evaluation.py (3 marks)
• test_otel.py (2 marks)
• test_core_sdk.py (1 mark)

pytest-asyncio underwent major internal changes between 0.23.3 and 1.x (including changes to default asyncio_mode, event-loop scoping, and fixture handling). There is also no asyncio_mode set in [tool.pytest.ini_options], which in older versions triggers a deprecation warning or affects behavior differently than in newer versions. Running pytest 9.0.2 + pytest-asyncio 0.23.3 is an untested combination likely to produce subtle failures or incorrect results.

How to fix

Update pyproject.toml to allow pytest-asyncio 1.3.0+, the first version that explicitly declares pytest<10,>=8.2:

"pytest-asyncio>=1.3.0,<2"

After updating the constraint, run uv lock to resolve to a compatible version and run the async test suite (pytest tests/ -m asyncio or similar) to confirm everything passes.

Step-by-step proof

1. pyproject.toml has pytest>=7.4,<10.0 (updated by this PR) — selects pytest 9.0.2 ✓
2. pyproject.toml has pytest-asyncio>=0.21.1,<1.2.0 (unchanged) — candidate versions: 0.21.x, 0.22.x, 0.23.x, 1.0.x, 1.1.x
3. Versions 1.0.x and 1.1.x declare pytest<9 → incompatible with 9.0.2, eliminated
4. Versions 0.24.x–0.26.x declare pytest<9 as well → eliminated
5. Only 0.21.x–0.23.x remain; resolver picks the highest: 0.23.3
6. 0.23.3 was released 2024-01-01, over a year before pytest 9.0 (2025-11-12) — it was never tested against pytest 9 internals
7. The resulting lock file contains pytest 9.0.2 + pytest-asyncio 0.23.3, an untested pairing for a codebase with 48 async tests

[claude]

🟡 The pytest-asyncio downgrade from 1.1.1 to 0.23.3 (a side effect of the pytest 9.0.2 bump) introduces DeprecationWarnings on every test run because asyncio_mode is not set in [tool.pytest.ini_options]. Tests will still pass since all 48 async tests already use @pytest.mark.asyncio decorators (compatible with strict mode), but the warning noise can be suppressed by adding asyncio_mode = "strict" to the [tool.pytest.ini_options] section in pyproject.toml.

Extended reasoning...

What the bug is and how it manifests

When pytest-asyncio 0.23.x runs without an explicit asyncio_mode setting, it emits a DeprecationWarning on every test session: "The configuration option asyncio_mode is unset, the default value strict will be used". This PR bumps pytest from 8.4.2 to 9.0.2, which as a side effect resolves the pytest-asyncio constraint differently — downgrading it from 1.1.1 to 0.23.3. The 0.23.x series requires the explicit asyncio_mode option to avoid deprecation warnings, whereas 1.1.1 handled the missing configuration silently.

The specific code path that triggers it

The [tool.pytest.ini_options] section in pyproject.toml (lines 20–26) contains only log_cli = true with no asyncio_mode setting. pytest-asyncio 0.23.3 checks for this option at startup, and when absent, defaults to strict mode while emitting the deprecation warning.

Why existing code doesn't prevent it

The project previously depended on pytest-asyncio>=0.21.1,<1.2.0, and the lock file resolved to 1.1.1. In that version, the missing asyncio_mode either defaulted silently or was handled differently — no deprecation warning was triggered. The PR's pytest upper bound change (from <9.0 to <10.0) causes uv to resolve a different compatible set of transitive dependencies, landing on pytest-asyncio 0.23.3 instead of 1.1.1.

What the impact would be

Tests will not fail — all 48 async tests use explicit @pytest.mark.asyncio decorators, which is exactly what strict mode requires. The only impact is noisy DeprecationWarning output on every pytest invocation, which pollutes CI logs and can mask real warnings.

How to fix it

Add asyncio_mode = "strict" to [tool.pytest.ini_options] in pyproject.toml:

[tool.pytest.ini_options]
log_cli = true
asyncio_mode = "strict"

Alternatively, resolving the pytest-asyncio version back to 1.1.1 (by explicitly pinning it) would also eliminate the warning, since 1.1.1 does not require explicit asyncio_mode configuration.

Step-by-step proof

1. Before this PR: uv.lock resolves pytest-asyncio to version 1.1.1, which does not emit the deprecation warning for a missing asyncio_mode.
2. After this PR: uv.lock resolves pytest-asyncio to version 0.23.3 (visible in the diff — the package entry changes from 1.1.1 to 0.23.3).
3. pytest-asyncio 0.23.3 checks for asyncio_mode at startup. Since [tool.pytest.ini_options] only has log_cli = true, the check fails to find asyncio_mode.
4. pytest-asyncio 0.23.3 emits: DeprecationWarning: The configuration option asyncio_mode is unset, the default value strict will be used.
5. All 48 async tests still pass (strict mode is compatible with explicit @pytest.mark.asyncio decorators), but the warning appears for every test session.