[issue35620] asyncio test failure on appveyor

2019-09-12 Thread Andrew Svetlov


Change by Andrew Svetlov :


--
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue35620] asyncio test failure on appveyor

2019-09-12 Thread Karthikeyan Singaravelan


Karthikeyan Singaravelan  added the comment:

asyncio tests are stable now and I couldn't find related reports. I guess it's 
fixed in one of the commits and also AppVeyor is not used anymore. I guess this 
can be closed as outdated.

--
nosy: +xtreak

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue35620] asyncio test failure on appveyor

2018-12-30 Thread Terry J. Reedy


Terry J. Reedy  added the comment:

My position is that tests that are known to occasionally fail independently of 
any changes in particular PRs should not be allowed to block merging.  In the 
context of CI, the failure is a lie.

One solution, and the easiest, is to disable the test.  That is all I could do 
here.

If the module/test author wants to keep running the test, another solution is 
to change the test so that bogus results are no longer seen as a failure by the 
test framework.  How depends on the situation.  Perhaps turn particular 
exceptions into a warning message?

In this case, there are multiple exceptions listed in the log:
OSError: [WinError 6] The handle is invalid x 2
OSError: [WinError 995] The I/O operation has been aborted because of either a 
thread exit or an application request, leading to
ConnectionResetError: [WinError 995] ...
OSError: [WinError 64] The specified network name is no longer available, 
leading to another ConnectionResetError.

I don't see am a little surprised at and don't understand the vague end failure 
message.  So I cannot suggest anything more specific.

The third solution I am thinking of is somehow change the test framework so we 
can somehow mark 'heisentests' as such and not count know false positives as 
merge-blocking failures.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue35620] asyncio test failure on appveyor

2018-12-30 Thread Andrew Svetlov


Andrew Svetlov  added the comment:

Do you mean an environment modification?

1 test altered the execution environment:
test_asyncio

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue35620] asyncio test failure on appveyor

2018-12-30 Thread Terry J. Reedy


New submission from Terry J. Reedy :

https://ci.appveyor.com/project/python/cpython/builds/21296354?fullLog=true
Blocked merge.  Passed on Azure Pipeline +- same time. Appveyor re-run passed.  
Please disable or weaken the false positive tests.

I will propose a different solution elsewhere, perhaps pydev.

--
components: Tests, asyncio
messages: 332757
nosy: asvetlov, pablogsal, terry.reedy, yselivanov
priority: normal
severity: normal
status: open
title: asyncio test failure on appveyor
type: behavior
versions: Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com