fix(ci): adopt asyncio_mode=auto and drop class-level asyncio marks

[andreibalas-uipath]

What changed and why

Affected packages: none — tests + root pytest config only; no version bump per ci_change_version rules (it only guards the two package source trees).

Every Test job since the switch to the centralized managed runner pool (#122, merged Aug 7 — the last green run was Aug 6) failed the same way: the full suite passes, then pytest crashes printing the warnings summary:

File ".../_pytest/_io/terminalwriter.py", line 168, in write_raw
    self._file.write(msg)
BlockingIOError: [Errno 11] write could not complete without blocking

On the managed pool the step's stdout pipe is in non-blocking mode, so when the warnings-summary burst outruns the runner's log reader, write() returns EAGAIN and pytest exits 1 — after all tests have passed. Only the Test job produces a burst large enough to fill the pipe buffer.

The burst was ~97% one warning

Of the ~1,278 warnings per run, ~1,050 were a single artifact: the seven provider integration classes carry a class-level @pytest.mark.asyncio (required under pytest-asyncio strict mode for the async tests inherited from langchain_tests), which also lands on every inherited sync test — and pytest-asyncio warns once per parametrized item:

PytestWarning: The test <Function ...> is marked with '@pytest.mark.asyncio' but it is not an async function.

Fix

Adopt the convention already used across the family (uipath-python's three packages and uipath-langchain-python all set it):

• asyncio_mode = "auto" + asyncio_default_fixture_loop_scope = "function" in root pyproject.toml ([tool.pytest.ini_options], new section)
• remove the 11 class-level @pytest.mark.asyncio decorators from tests/langchain/clients/*/test_integration.py

Async tests need no decorator under auto mode; the sync tests no longer carry a mark, so the warning flood disappears at its source. Explicit method-level @pytest.mark.asyncio marks elsewhere in tests/ remain valid under auto mode.

Verification

• Reproduced the mechanics in isolation: a class-level-marked suite emits the warning per sync test under both strict and auto mode; with auto mode and no class marks, sync and async tests pass warning-free.
• ruff check, ruff format --check, pyright, and pytest tests pass locally with results identical to main (632 passed; the local LLMGW_* env setup errors are pre-existing and identical on main).
• Expected CI effect: warnings drop from ~1,278 to the residual ~25 genuine ones, shrinking the summary burst ~97% — below the level that has ever triggered the pipe crash (sibling repos on the same pool with small outputs don't crash).

Note for the runner-pool owners

The underlying hazard is in the pool's job wrapper making the log pipe non-blocking (and re-asserting it mid-job): any repo on the pool with a large enough output burst — e.g. a mass-failure traceback dump — can still hit BlockingIOError. This PR removes this repo's chronic trigger; the root cause is worth fixing at the worker level.

🤖 Generated with Claude Code