Unit Test Results

See test report for an extended history of previous test failures. This is useful for diagnosing flaky tests.

      9 files  ±0        9 suites  ±0   3h 6m 6s ⏱️ - 2m 9s
 18 139 tests ±0   16 924 ✅ ±0   1 215 💤 ±0  0 ❌ ±0 
162 479 runs  ±0  150 386 ✅ +1  12 093 💤  - 1  0 ❌ ±0 

Results for commit b172c5f7. ± Comparison against base commit a9d0e52.

♻️ This comment has been updated with latest results.

Done. Note that UP038 has been deprecated end eventually removed. Ignoring it now emits a warning.

This is a new issue. Is it caused by this PR?

FAILED dask/bytes/tests/test_http.py::test_parquet[pyarrow] - pyarrow.lib.ArrowInvalid: Invalid number of indices: 0

The remote file nation.impala.parquet appears to be available:

@jacobtomlinson I may be missing something here, I don't see how the failure could be related to the changes in this PR. I haven't changed actual code, just linting tools and linting directives. This is certainly caused by the update of a dependency, but I cannot identify which one. Time permitting, I'll download logs from both branches and diff them to find the culprit.

After rebasing, most tests pass. Some transient error probably caused previous failures. The only test that fails shows a new error, probably some "random" error again. Could you please restart the failing test? Eventually it should pass.

I think the tests have become fragile for some reason, and fail "randomly". I don't know enough about this package to fix this fragility, it's probably related to multiprocessing.

Based on other PRs that have been raised recently I've not found CI to be very flaky, so I'm concerned that this PR is behaving this way. I agree that the changes here should just be format/lint related and not change actual functionality. But the fact the CI keeps failing in these ways makes me nervous that there is in fact some functional change in here that we've missed.

I know, but I've looked again and again and I only see changed # noqa directives and associated comments in the Python source code. The only "change" in actual code is a mere formatting change:

-         raise ValueError(
-             f"Index column {index_name} not found in statistics"  # noqa: E713
-         )
+         raise ValueError(f"Index column {index_name} not found in statistics")

The only possible effect I can imagine is that ruff runs much faster than flake8/pyupgrade, and this has an effect on tests running in parallel or after the linter somehow - but again the failure would result from a preexisting race condition in other tests.

Also note that the error is stochastic, as shown by the success of the new run of the previously failing test. This does seem to point to some sort of race condition.

I see you've been able to identify the initial error as an effect of #47981.

How about I rebase one last time onto your related fix #12124 and see how it goes?