Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

ci: unit tests pin Python 3.12 while the package advertises 3.14 support

Open Beginner friendly
  • Is something wrong?
#8,231 3 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@huong8373tt-beep is already working on this.

Since Oct 29, 2026.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
74/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
github-actions, python
Domain
ci-cd

Research direction

Read .github/workflows/tests.yml and livekit-agents/pyproject.toml to compare the tested Python versions with requires-python. Check whether the project dependencies and unit tests support Python 3.14, then update the unit test coverage or narrow the advertised range as the maintainers decide. Done when the supported Python range and runtime test coverage agree, with any exception explained.

Written by the indexing model from the issue text.

Description

What

livekit-agents/pyproject.toml advertises requires-python = ">=3.10,<3.15", so 3.14 is a supported interpreter, but no runtime job ever runs on it:

  • .github/workflows/tests.yml pins python-version: "3.12" in all three jobs — blockguard-tests (L32), unit-tests (L56), evaluation (L83);
  • .github/workflows/ci.yml varies the interpreter only for mypy (["3.10", "3.13"]).

So the runtime test suite only ever sees 3.12. A break that is specific to 3.13/3.14 is green by construction.

Evidence that this is not theoretical

#8162 fixed exactly that class: ndarray.resize() rejects an array that is still referenced, and on 3.14 it also rejects one only held by an attribute, so VAD.update_options raised ValueError for users on that interpreter while unit-tests stayed green. The change now copies into a new array instead.

The CI gap is what let it ship — the fix is fine, the matrix is the problem. The same shape will recur for anything that depends on interpreter behaviour rather than our own logic.

Proposal

Cheapest option first, in order of preference:

  1. One 3.14 leg on unit-tests only (matrix entry or a second job), not the whole matrix — the job count stays flat and the interpreter-sensitive code paths are covered.
  2. If some dependency does not support 3.14 yet, narrow the promise instead: requires-python = ">=3.10,<3.14" plus a note, so the advertised range matches what CI actually proves.

Either way the rule worth stating is that the advertised requires-python range and the tested interpreters should not disagree without a comment saying why.

Happy to send the workflow change (option 1) if that is the direction — I did not want to add a CI job in someone else's bug-fix PR.

Dominant language
Python
Stars
14.6k
Forks
3.9k
Avg merge
2d 5h
Merged PRs (30d)
232

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from livekit/agents

All issues in livekit/agents

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.