bpo-41682: skip test_sendfile_close_peer_in_the_middle_of_receiving in test_asyncio
#30801
Conversation
… in `test_asyncio`
|
If I remember correctly, all failures are on Windows. Perhaps we can skip on Windows only? I generally don't feel comfortable with just skipping a flakey test; it tends to lead to the issue being forgotten and possibly hiding real bugs. OTOH, the noise level on the CI is unbearable at the moment. |
| @@ -456,6 +456,8 @@ def test_sendfile_ssl_close_peer_after_receiving(self): | |||
| # themselves). | |||
| @unittest.skipIf(sys.platform.startswith('sunos'), | |||
| "Doesn't work on Solaris") | |||
| @unittest.skipIf(sys.platform == "win32", | |||
| "It is flaky on Windows and needs to be fixed") # TODO: bpo-41682 | |||
There was a problem hiding this comment.
nitpick: I'd probably include the bug number in the skip message in case that's all the viewer sees.
There was a problem hiding this comment.
I suggest to not include it in the skip message. Otherwise, https://bugs.python.org/issue41682 will be spammed with pull requests unrelated to the change, if a CI job fails with this message. The bot which mentions PR in bpo searchs for "bpo-xxx" anyway in a PR :-(
There was a problem hiding this comment.
LGTM. I would prefer to fix it, but well, since Septembre 2020, no one was available to investigate this bug, whereas this bug annoys anyone paying attention to Python CIs for 1 year and a half.
But please don't close https://bugs.python.org/issue41682 until the real issue is fixed.
vstinner
added
needs backport to 3.9
…nGH-30801) (cherry picked from commit 1ded8ed) Co-authored-by: Nikita Sobolev <[email protected]>
|
GH-30811 is a backport of this pull request to the 3.9 branch. |
…nGH-30801) (cherry picked from commit 1ded8ed) Co-authored-by: Nikita Sobolev <[email protected]>
|
GH-30812 is a backport of this pull request to the 3.10 branch. |
|
Can someone please try to figure out what caused that test to fail, and why it got worse recently? |
I also noticed that the step started to fail more recently recently. Maybe a CI updated Windows. I saw an announcement that Azure Pipelines or GitHub Actions (oops, I don't recall anymore) is being upgrade incrementally to Windows Server 2022, for example. About the bug itself, it has been reported in September 2020 and so far, no one was available to investigate the issue: https://bugs.python.org/issue41682 |
) (cherry picked from commit 1ded8ed) Co-authored-by: Nikita Sobolev <[email protected]>
) (GH-30812) (cherry picked from commit 1ded8ed) Co-authored-by: Nikita Sobolev <[email protected]> Co-authored-by: Nikita Sobolev <[email protected]>
@zooba modified the config yesterday to request explicitly Windows 2022 for the Windows jobs of the Azure Pipelines: commit 70c1646. My PR #30817 confirms that Windows Server 2022 is now used on Azure Pipelines for the Windows jobs. So maybe the test fails more frequently or always fails on Windows Server 2022. |
…nGH-30801) (cherry picked from commit 1ded8ed) Co-authored-by: Nikita Sobolev <[email protected]>
It is failing way too often:
Most of the commits above failed due to this single test.
I don't know how to fix it, but at least we can decrease the noise.
https://bugs.python.org/issue41682