Skip to content

feat: add a job timeout to the Python unit tests workflow - #333

Open
vdusek wants to merge 3 commits into
mainfrom
ci/unit-tests-job-timeout
Open

vdusek wants to merge 3 commits into
mainfrom
ci/unit-tests-job-timeout

Conversation

@vdusek

@vdusek vdusek commented Oct 12, 2026

Copy link
Copy Markdown
Contributor

Adds a timeout_minutes input (default 60) that sets timeout-minutes on the unit-test matrix job. Without it a hung test holds the job until GitHub's 6-hour limit, which happened in crawlee-python. The slowest crawlee-python unit-test job in the last 8 green master runs took 7 minutes, so 60 leaves plenty of room. Callers that need more can raise it.

Related: apify/crawlee-python#2287

✍️ Drafted by Claude Code

@vdusek vdusek added adhoc Ad-hoc unplanned task added during the sprint. t-tooling Issues with this label are in the ownership of the tooling team. labels Oct 12, 2026
@vdusek vdusek self-assigned this Oct 12, 2026
@vdusek
vdusek requested a review from janbuchar October 12, 2026 07:20
@vdusek
vdusek marked this pull request as ready for review October 12, 2026 07:20
@apify-service-account apify-service-account added the tested Temporary label used only programatically for some analytics. label Oct 12, 2026
@vdusek

vdusek commented Oct 12, 2026

Copy link
Copy Markdown
Contributor Author

The two failing apify-pr-toolkit checks come from stale repo-level workflows, not from this change. Removing them in #334; this PR goes green once that's merged.

✍️ Drafted by Claude Code

vdusek added a commit to apify/crawlee-python that referenced this pull request Oct 13, 2026
#2287)

Two ubuntu / Python 3.10 CI failures on master.

`test_recurring_task.py::test_execution` slept 200 ms and expected at
least 3 calls at a 30 ms delay, but a slow runner got 1
([run](https://github.com/apify/crawlee-python/actions/runs/38214082347/job/114694625489)).
It now waits for the third call with a 5 s timeout and no longer needs
`run_alone`.

A worker hung in a fixture teardown and the job ran until GitHub
cancelled it after 6 hours
([run](https://github.com/apify/crawlee-python/actions/runs/38172798916/job/114568777725)).
The cause is in `backports.asyncio.runner`, which pytest-asyncio uses on
3.10. `Runner.run(coro, context=...)` patches `contextvars.copy_context`
process-wide while it creates the task, so the test server's thread can
pick up the fixture's context. When both threads enter it at once,
`Context.run` raises `cannot enter context: ... is already entered`, the
task step is dropped, and the teardown waits forever. On Python 3.10,
`pytest-asyncio` is pinned to 1.0.x, the last release before it started
using the backports runner. That pin also brings in pytest 8, and ty
can't type-check `pytest.skip()` with it, so the six runtime skips in
the storage tests raise `pytest.skip.Exception` instead.

For any future hang, `timeout_method = "thread"` kills the stuck worker
(the default signal method never fired in the 6 h run), and
`faulthandler_timeout = 600` dumps every thread's stack into the log.
The job-level cap is in apify/workflows#333.

*✍️ Drafted by Claude Code*
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

adhoc Ad-hoc unplanned task added during the sprint. t-tooling Issues with this label are in the ownership of the tooling team. tested Temporary label used only programatically for some analytics.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants