[n-o-t-mugen]

The Windows engine job took 35 to 43 minutes against about 6 on Ubuntu. No single test causes it: the time comes from app start-up (SQLite disk flushes on NTFS), a one-time litellm import, real browsers and processes, and a slow, variable runner.

This runs the engine tests in parallel with pytest-xdist (-n auto) and sets the limit back to 40 minutes. The tests already isolate their home folder, keychain and ports, so no test changes were needed.

Closes #377

How I tested it

On Windows with CI's settings:

• One process: 2175 passed (unchanged).
• -n auto: 2175 passed in about 2 minutes, down from about 11. One rare failure in test_mailbox_transport didn't reproduce in 6 more stress runs.
• ruff check: clean.

This PR's CI run will confirm the Windows time is under 20 minutes.

Checklist

• pytest passes locally, in one process and in parallel
• ruff check sentient tests is clean
• No contract change
• No keys, tokens or personal data

Summary by CodeRabbit

• Tests
  • Engine tests now run in parallel, and the CI time limit for the test job is 40 minutes.
  • The development setup includes the tooling needed to run tests in parallel.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Organization UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: 7485632a-074e-4574-850e-f0745eb3b609

📥 Commits

Reviewing files that changed from the base of the PR and between 96a9a2e and 323f24d.

📒 Files selected for processing: 2

• .github/workflows/ci.yaml
• pyproject.toml

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.

📝 Walkthrough

The development dependencies now include pytest-xdist. The engine test job runs pytest with -n auto, and its timeout is reduced from 60 to 40 minutes.

Changes: Engine test parallelism

Layer / File(s)	Summary
Enable parallel CI tests pyproject.toml, .github/workflows/ci.yaml	The development dependencies add pytest-xdist. The engine test job uses -n auto and has a 40-minute timeout.

Priority: ➖ Normal

Estimated code review effort: 2 (Simple) | ~8 minutes

Change: Other · Severity of issue fixed: Medium

Merge Risk: ⚪ Minimal · up to 323f2

The Windows job installs the parallel-test dependency before running the suite, and the inspected keyring and mailbox paths are isolated. One intermittent mailbox-test failure was reported, but its cause is unknown; no actionable merge-blocking issue is established.

Security architecture risk: 🔵 Low · up to 323f2

The change is confined to test execution and a development dependency. Existing isolation controls limit cross-worker state sharing, and no increased credential authority was identified. Cleanup after abrupt worker termination remains unverified.

Retained concerns
No architecture-level concerns identified.

Security review details

Security Blast Radius

• inferred — The demonstrated exposure change is concurrent execution within each engine-test runner. The compared changes do not add deployment steps, workflow privileges, or production state access.

Trust Boundaries and Controls

• observed — Secret service names distinguish non-default application homes. Inspected credential-writing test scopes replace the real backend with in-memory stores, countering the proposed cross-worker keyring-write path. Distinct service names alone would not prove concurrent file-backend write safety.

Resilience and Maintainability Implications

• inferred — Normal cleanup paths do not establish cleanup after a forcibly terminated pytest worker or CI job. The new worker topology makes this a relevant coverage limit, but the available evidence does not establish persistent credential exposure or a security regression.

Pre-merge checks: 4 · 1

Failed checks: 1 inconclusive

Check name	Status	Explanation	Resolution
Linked Issues check		Issue #377 requires the Windows engine job to complete in under 20 minutes and the timeout to return to 40 minutes. The workflow sets timeout-minutes: 40 and runs pytest with -n auto. The PR descr…	Provide a completed Windows engine-job result that shows the full test suite finishes in under 20 minutes. The 40-minute timeout change is already implemented.

Passed checks: 4 passed

Check name	Status	Explanation
Out of Scope Changes check		The changed files are limited to the engine workflow and the development dependency list. The workflow changes enable pytest-xdist and restore the 40-minute timeout, which directly implement issue #37…
Docstring Coverage		No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0…
Description Check		Check skipped - CodeRabbit’s high-level summary is enabled.
Title check		The title clearly identifies both main changes: parallel engine tests and restoring the Windows time limit to 40 minutes.

Full details: Linked Issues check

Explanation

Issue #377 requires the Windows engine job to complete in under 20 minutes and the timeout to return to 40 minutes. The workflow sets timeout-minutes: 40 and runs pytest with -n auto. The PR description reports a local Windows result of about 2 minutes with -n auto, but it states that the PR CI run will confirm the under-20-minute target. The reviewed repository evidence does not establish a completed Windows CI result.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

_{A rabbit packs the tests to run,
With workers hopping one by one.
The clock now gives them forty more,
While pytest bounds across the floor.
The burrow hums; the checks are done.}

_{Comment @coderabbitai help to get the list of available commands.}

[n-o-t-mugen]

I have read the CLA Document and I hereby sign the CLA

[itsskofficial]

Thanks @n-o-t-mugen, great find, and a clean fix. The Windows engine job went from about 40 minutes to 18 (2176 passed, 2 skipped), and Ubuntu from 6.5 to under 4. Running in parallel with no test changes is the best outcome. Merging.