[Bug] tests/test_fasth3_packaging.py: stale TORCH_CUDA_ARCH_LIST assertions fail since #1833

Open Beginner friendly
  • Is something wrong?
#1,928 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

@zyuanbing is already working on this.

Since Oct 8, 2026.

  • #1939 by @zyuanbing — open

Assessment

Difficulty
1/5
Estimated time
Under an hour
Newbie friendliness
94/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
github-actions, python
Domain
ci-cd, testing

Research direction

Read tests/test_fasth3_packaging.py and compare its two TORCH_CUDA_ARCH_LIST assertions with the Blackwell entries in .github/workflows/publish-kernel.yml. Run python -m pytest tests/test_fasth3_packaging.py -q first; done when the assertions match the workflow and the test passes.

Written by the indexing model from the issue text.

Description

bug installation platform scope: attention scope: kernel
Describe the bug

tests/test_fasth3_packaging.py::test_kernel_release_matrix_can_publish_data_center_blackwell_wheels
fails on main because two of its assertions still expect the pre-#1833
TORCH_CUDA_ARCH_LIST values in .github/workflows/publish-kernel.yml.

History: the test file predates #1812 (it exists at the #1748 tree, 2026-08-23,
as test_kernel_release_matrix_can_publish_sm100a_wheels with the same two arch
assertions). #1812 (7bb76b5ec99807a66aa3047b901f15019abe0f00, 2026-09-03)
renamed the test to ...data_center_blackwell_wheels and added the two
sm_100a/sm_103a gencode assertions, leaving the arch strings unchanged.
#1833 (merged 2026-09-12, merge commit aef4e9b3b1423be9d5e39ca463fb085b85c221f6)
then added 10.3a to the two Blackwell wheel arch lists ("The publish workflow
lists 10.3a explicitly for the two Blackwell wheels") without updating the
test — that is when the two assertions became stale.

Stale assertions (tests/test_fasth3_packaging.py:37-38):

assert 'TORCH_CUDA_ARCH_LIST="9.0a;10.0a;12.0a"' in workflow
assert 'TORCH_CUDA_ARCH_LIST="10.0a;12.0a"' in workflow

Actual values in .github/workflows/publish-kernel.yml:

Build leg Line TORCH_CUDA_ARCH_LIST
aarch64 (cu130) 179 10.0a;10.3a;12.0a
x86_64 cu130 183 9.0a;10.0a;10.3a;12.0a
x86_64 cu126 188 9.0a

The test's other three assertions still hold: arch=compute_100a,code=sm_100a and
arch=compute_103a,code=sm_103a in fastvideo-kernel/CMakeLists.txt
(:452, :456), and patchelf==0.17.2.4 in the workflow (:202).

This is a test-only staleness bug: the workflow itself is correct per #1833. No
CI lane runs the top-level tests/ suite (.buildkite/scripts/unit_test.sh and
the lane scripts run fastvideo/tests/**; ci-macos-mlx.yml runs
fastvideo/tests/mlx/** + two platforms tests; ci-precommit.yml runs lint
hooks only), which is why this has been failing unnoticed since #1833 merged.

Reproduction
python -m pytest tests/test_fasth3_packaging.py -q

Result (reproduced at 7f03e03d; the test and workflow files are unchanged on
current main, so the result is identical there):

.F                                                                       [100%]
=================================== FAILURES ===================================
_____ test_kernel_release_matrix_can_publish_data_center_blackwell_wheels ______
>       assert 'TORCH_CUDA_ARCH_LIST="9.0a;10.0a;12.0a"' in workflow
E       assert 'TORCH_CUDA_ARCH_LIST="9.0a;10.0a;12.0a"' in '...'
tests/test_fasth3_packaging.py:37: AssertionError
=========================== short test summary info ============================
FAILED tests/test_fasth3_packaging.py::test_kernel_release_matrix_can_publish_data_center_blackwell_wheels
1 failed, 1 passed

Suggested fix (two lines, verified locally to make the file pass 2/2):

--- a/tests/test_fasth3_packaging.py
+++ b/tests/test_fasth3_packaging.py
@@ -37,2 +37,2 @@
-    assert 'TORCH_CUDA_ARCH_LIST="9.0a;10.0a;12.0a"' in workflow
-    assert 'TORCH_CUDA_ARCH_LIST="10.0a;12.0a"' in workflow
+    assert 'TORCH_CUDA_ARCH_LIST="9.0a;10.0a;10.3a;12.0a"' in workflow
+    assert 'TORCH_CUDA_ARCH_LIST="10.0a;10.3a;12.0a"' in workflow

Optional follow-up: run the top-level tests/ suite (or at least
tests/test_fasth3_packaging.py) in a CI lane so packaging-contract staleness is
caught automatically.

Environment
  • FastVideo main at 33d8173 (2026-10-06; test, workflow and CMake lines unchanged since 6ded84ee, 2026-10-04);
    identical failure at 7f03e03dc6561f12815794294384b730bda4dbbb (the #1884
    merge commit)
  • Python 3.12.3, pytest 9.1.1, Linux aarch64
  • The test only reads repository files; no GPU, model, or network needed
Dominant language
Python
Stars
4.6k
Forks
486
Avg merge
3d 15h
Merged PRs (30d)
74

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

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 hao-ai-lab/FastVideo

All issues in hao-ai-lab/FastVideo

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.