CI: azure timeouts

[mzeitlin11]

Based on the logging in #43611, in both timeout cases, the last test gw0 ran was before the hypothesis test in test_parse_dates (this is a giant test - 56 parameterizations, hypothesis does 100 examples by default).

Not sure why this would be the cause, couldn't find any issues about it that might explain a deadlock or something like that, but maybe this will help? Regardless of fixing timeouts, it makes sense for these to be slow

[mzeitlin11]

Maybe something similar to HypothesisWorks/hypothesis#2340?

[mzeitlin11]

Hmm this didn't work - new guess - the logging seems to stop around parser tests - maybe the fact that we use the same parser object across tests can cause deadlock (or issue is some mutation is happening?)

[mzeitlin11]

We're at ~5 in a row on azure not timing out. Will keep running azure, but this is ready for review from my side. Summary of changes:

1. Mark hypothesis tests as slow
2. For parser fixtures, ensure we generate new objects instead of sharing them
3. skip pyarrow tests which can deadlock, xref CI/BUG: pyarrow read_csv deadlock #43650
   (EDIT: just noticed more timeout cases on deadlock in CI: debug azure timeouts #43611. Another option might be to just replace all pyarrow xfails with skips)

[jreback]

Mark hypothesis tests as slow

is there some option that can set on hypthosesis instead? the point of these tests is to find holes in our tests, which are almost all fast, so this just remove this entirely (which maybe ok). but then we should just do that.

[jreback]

can you add some comments here on when to xfail vs skip

[mzeitlin11]

Yep, will do

[mzeitlin11]

is there some option that can set on hypthosesis instead? the point of these tests is to find holes in our tests, which are almost all fast, so this just remove this entirely (which maybe ok). but then we should just do that.

We could set fewer examples to run (but at some point that defeats the purpose of hypothesis). I thought on running on slow was a good compromise since it will still run on some builds, just fewer.

Regardless, the important change here is skipping pyarrow for the hypothesis parse_dates test - will just remove the slow markers for now since it turned out pyarrow was the cause of the timeout, not the hypothesis tests sometimes running extremely slowly

[jreback]

kk lgtm. ping when ready to merge (or just go ahead)

[jreback]

note that I think we are seeing something similar on 1.3.4, but we didn't merge the pyarrow csv reader so prob something else.

[mzeitlin11]

note that I think we are seeing something similar on 1.3.4, but we didn't merge the pyarrow csv reader so prob something else.

Good to know - certainly possible there are other potential timeout-causing issues unrelated to pyarrow. Will keep running azure pipelines on #43611 to see if anything else comes up. This should at least make timeouts less frequently hopefully

[jreback]

thanks @mzeitlin11 nice improvement here. Yeah let's keep an eye on 1.3.4