You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[BUG] Diagnose and fix current test failures in CI and local #1544
Update - 29 Dec, 2025: Now the tests are failing in local as well as on CI as pointed by @fkiraly
While following the testing-your-installation guide, running pytest locally results in multiple test failures.
We should investigate the failing tests and debug them.
Todos after resolving tests:
remove the pytest.xfails
set sklearn-only: "false" in the include jobs in the test.ymltest job
Note: originally it was thought that only local tests fail while main CI passes. This was a confusion that was caused by a state of the repo in which main was no longer used and develop used as the main branch, and for releases. This has since been rectified (main is now the main branch), so remote CI and local failures agree.
Quite a few tests rely on connections to the servers (both production and test). In some cases they even rely on server state. This means that it's possible for tests to fail "randomly". I'm on mobile so I can't easily search but I do believe there is already a different issue about making tests rely on connections less by a combination of reducing the surface each individual test tests, and using mocked responses.
Reacted by Jigyasu, Eman Abdelhaleem and Rohan Sen
@EmanAbdelhaleem agreed to add temporary skips in a PR so other PR do not get blocked (or delayed) by the recurring failures. @rohansen856 will investigate and try to debug.
Quite a few tests rely on connections to the servers (both production and test). In some cases they even rely on server state. This means that it's possible for tests to fail "randomly". I'm on mobile so I can't easily search but I do believe there is already a different issue about making tests rely on connections less by a combination of reducing the surface each individual test tests, and using mocked responses.
@PGijsbers, the test failures are not random but consistent, always the same on all the CI steps.
now, upon further investigation, the sklear and production and sklearn and not production is run separately on the CI test.yaml:
# Ubuntu Test Server (line 106-113)
- name: Run tests on Ubuntu Testif: matrix.os == 'ubuntu-latest'run: | if [ ${{ matrix.sklearn-only }} = 'true' ]; then marks='sklearn and not production' else marks='not production' fi pytest -n 4 --durations=20 --dist load -sv -m "$marks"# Ubuntu Production Server (line 114-121)
- name: Run tests on Ubuntu Productionif: matrix.os == 'ubuntu-latest'run: | if [ ${{ matrix.sklearn-only }} = 'true' ]; then marks='sklearn and production' else marks='production' fi pytest -n 4 --durations=20 --dist load -sv -m "$marks"
now, what i am trying to do next is running the tests locally inside a CI like environment using a open source tool act (https://github.com/nektos/act/releases)
The thing that strikes me as odd is that it worked 3 weeks ago (#1502 - the PR merges to "develop" but that's the same branch as the current "main" after the rename). That's why I had assumed they were sporadic failures. Thanks for the investigation.
A quick scan of the failing test tells me this is related to test server state (at least a large swath of them). I don't know what happened, I am asking around with the other core contributors that would have had access. I'll try to see if I can fix this on the test server side. It's possible a few additional tests may fail in the meantime.
So, currently failing tests are marked with xfail to make them pass temporarily by @EmanAbdelhaleem in Pr #1572
My approach is first discarding the commit bt Eman through a rebase then picking upp the tests and investigating why they are failing (git rebase -i 3b995d9^). I have setup both the php and fastapi backend locally and using those i think most of the complexities regarding the errors returned from test.openml.org would be easier to resolve. @fkiraly please do inform me if you think this approach has any problem...
@EmanAbdelhaleem, can you please always state the condition under which tests are failing? local, remote, what version/OS if that is relevant
That was a list of the most frequent failed tests in the failed remote jobs. I skipped all of them and more (less frequent failed tests) back then in my previous merged PR #1587 . I don't have more details about these tests, they were from many different jobs.
@EmanAbdelhaleem, can you please always state the condition under which tests are failing? local, remote, what version/OS if that is relevant
From the above shared list, all these stated tests are marked with uses_test_server so I believe they must have been run and failed locally and skipped on remote.
@EmanAbdelhaleem, can you please always state the condition under which tests are failing? local, remote, what version/OS if that is relevant
From the above shared list, all these stated tests are marked with uses_test_server so I believe they must have been run and failed locally and skipped on remote.
This is an old list of test failures, the one I sent you on discord before the uses_test_server mark. Dr. Franz was asking if we had a similar list this morning. That's why I mentioned it.
Got a sporadic error here because the error no longer occurred after I made a dummy (empty) commit. Commenting here under the assumption that this is the issue tracking sporadic errors.
Activity
rohansen856 commentedon Dec 25, 2025
I would like to work on this issue. Looking into it now.
PGijsbers commentedon Dec 25, 2025
Quite a few tests rely on connections to the servers (both production and test). In some cases they even rely on server state. This means that it's possible for tests to fail "randomly". I'm on mobile so I can't easily search but I do believe there is already a different issue about making tests rely on connections less by a combination of reducing the surface each individual test tests, and using mocked responses.
rohansen856 commentedon Dec 26, 2025
Did some digging and tried to backtrack the test calls and found this:
Call Stack:
The 20th dataset throws error when called from local:
https://test.openml.org/api/v1/xml/data/features/20Got this when i checked the url myself:
Although i am still looking as to the root cause of the failures i have these doubts about why it locally fails but CI Passes:**
/.github/workflows/test.ymlruns tests in two separate steps:productionmarker ->marks='sklearn and not production'productionmarker ->marks='sklearn and production'@pytest.mark.sklearn()but NOT@pytest.mark.production()Will update on the matter as i dig more into it!
[-][MNT] Local pytest failures despite CI passing on main[/-][+][MNT] Test failures in CI and local[/+]fkiraly commentedon Dec 29, 2025
@EmanAbdelhaleem agreed to add temporary skips in a PR so other PR do not get blocked (or delayed) by the recurring failures. @rohansen856 will investigate and try to debug.
EmanAbdelhaleem commentedon Dec 29, 2025
I am working on marking these failures as xfail temporarily
mark.xfail for failures in issue openml#1544
[BUG] Temporarily fix issue #1544 by marking the failed tests as expe…
fkiraly commentedon Dec 29, 2025
@jgyasu, we need to investigate exactly which tests are failing when:
sklearn-onlyFalsevsTrueflag in CIfkiraly commentedon Dec 29, 2025
@PGijsbers, the test failures are not random but consistent, always the same on all the CI steps.
fkiraly commentedon Dec 29, 2025
Failures appear under the following conditions on CI:
sklearn-onlyisFalse- 42 additional failureswindows-latest- 41 failuresThese should be investigated.
rohansen856 commentedon Dec 30, 2025
So i have been trying to run the tests with all different configurations possible. Attaching all the results below:
With
sklearn and productionWith
sklearn and not productionRunning all of them together
rohansen856 commentedon Dec 30, 2025
now, upon further investigation, the
sklear and productionandsklearn and not productionis run separately on the CItest.yaml:now, what i am trying to do next is running the tests locally inside a CI like environment using a open source tool
act(https://github.com/nektos/act/releases)PGijsbers commentedon Dec 31, 2025
The thing that strikes me as odd is that it worked 3 weeks ago (#1502 - the PR merges to "develop" but that's the same branch as the current "main" after the rename). That's why I had assumed they were sporadic failures. Thanks for the investigation.
A quick scan of the failing test tells me this is related to test server state (at least a large swath of them). I don't know what happened, I am asking around with the other core contributors that would have had access. I'll try to see if I can fix this on the test server side. It's possible a few additional tests may fail in the meantime.
[MNT] Update xfail for new test server state (#1585)
[MNT] extend CI to newer python versions, deprecate python versions 3…
[-][MNT] Test failures in CI and local[/-][+][BUG] Diagnose and fix current test failures in CI and local[/+]rohansen856 commentedon Jan 6, 2026
So, currently failing tests are marked with
xfailto make them pass temporarily by @EmanAbdelhaleem in Pr #1572My approach is first discarding the commit bt Eman through a rebase then picking upp the tests and investigating why they are failing (git rebase -i 3b995d9^). I have setup both the php and fastapi backend locally and using those i think most of the complexities regarding the errors returned from
test.openml.orgwould be easier to resolve.@fkiraly please do inform me if you think this approach has any problem...
fkiraly commentedon Jan 9, 2026
@PGijsbers, I think it is due to race conditions when you run multiple test runs in parallel, or aborted test runs. See #1586
EmanAbdelhaleem commentedon Jan 12, 2026
This is a list of the most repeated failed tests in the failed jobs:
fkiraly commentedon Jan 12, 2026
@EmanAbdelhaleem, can you please always state the condition under which tests are failing? local, remote, what version/OS if that is relevant
EmanAbdelhaleem commentedon Jan 12, 2026
That was a list of the most frequent failed tests in the failed remote jobs. I skipped all of them and more (less frequent failed tests) back then in my previous merged PR #1587 . I don't have more details about these tests, they were from many different jobs.
geetu040 commentedon Jan 12, 2026
From the above shared list, all these stated tests are marked with
uses_test_serverso I believe they must have been run and failed locally and skipped on remote.EmanAbdelhaleem commentedon Jan 13, 2026
This is an old list of test failures, the one I sent you on discord before the
uses_test_servermark. Dr. Franz was asking if we had a similar list this morning. That's why I mentioned it.satvshr commentedon Jan 31, 2026
Got a sporadic error here because the error no longer occurred after I made a dummy (empty) commit. Commenting here under the assumption that this is the issue tracking sporadic errors.
[MAINT] Remove skip markers because tests work again (#1781)