Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Xfail failing test #6211

Merged
merged 5 commits into from Jan 31, 2022
Merged

Xfail failing test #6211

merged 5 commits into from Jan 31, 2022

Conversation

max-sixty
Copy link
Collaborator

@keewis
Copy link
Collaborator

keewis commented Jan 30, 2022

makes sense, feel free to merge as soon as the CI is green. That way, we can avoid having the CI fail in other PRs (this is not just a upstream-dev issue anymore)

@mathause
Copy link
Collaborator

Can I suggest you xfail in

class TestVariableWithDask(VariableSubclassobjects):

(sorry, could have done this myself...)

@max-sixty
Copy link
Collaborator Author

Can I suggest you xfail in

No prob, you do lots!

@max-sixty
Copy link
Collaborator Author

We have another couple of failures though. I'll xfail them but please could someone who knows the dask interface better check them out and assess if we should raise them on the dask repo?

@mathause
Copy link
Collaborator

I haven't seen them fail before - were they just flaky?

@max-sixty
Copy link
Collaborator Author

I haven't seen them fail before - were they just flaky?

More than a one-off — I got them multiple times. Though they look like tests that are liable to be flaky...

@max-sixty
Copy link
Collaborator Author

RTD is being slow, but I'll merge regardless so we can return to green

@max-sixty max-sixty merged commit aab856b into pydata:main Jan 31, 2022
@max-sixty max-sixty deleted the xfail branch January 31, 2022 01:49
@@ -184,6 +184,7 @@ def test_dask_distributed_cfgrib_integration_test(loop) -> None:
assert_allclose(actual, expected)


@pytest.mark.xfail(reason="https://github.com/pydata/xarray/pull/6211")
@gen_cluster(client=True)
async def test_async(c, s, a, b) -> None:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@crusaderky can you take a look if you have the time?

@crusaderky
Copy link
Contributor

More than a one-off — I got them multiple times. Though they look like tests that are liable to be flaky...

They are both tests that fail on the cleanup of @gen_cluster, and specifically on check_process_leak.
However, in both cases, the test itself doesn't spawn any processes. What I think is happening is that something unrelated, at some point before the failing tests, spawned a subprocess that has become unresponsive to SIGTERM.
I'm updating check_process_leak to be more aggressive in the cleanup before the test.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants