Attempt to reduce flakiness of PythonVirtualeEnv test_airflow_context

[potiuk]

We have a global limit (60 seconds) for individual test execution,
however 'test_airflow_context' of the Python Virtualenv test might take longer in
case they are run in parallel - because they are using dill serialization
including a lot of serializable data from the context of the task.

We give the test 120 seconds to complete now.

---

^ Add meaningful description above

Read the Pull Request Guidelines for more information.
In case of fundamental code change, Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in UPDATING.md.

[github-actions]

The PR most likely needs to run full matrix of tests because it modifies parts of the core of Airflow. However, committers might decide to merge it quickly and take the risk. If they don't merge it quickly - please rebase it to the latest main at your convenience, or amend the last commit of the PR, and push it with --force-with-lease.

[uranusjr]

I wonder why this takes so long in the first place, virtualenv creation should generally be lightning fast. Probably because virtualenv is trying to update its embedded wheels (pip, setuptools, and wheel) automatically? We should try to disable this by passing --no-periodic-update.

https://virtualenv.pypa.io/en/stable/user_guide.html#embed-wheels-for-distributions

[potiuk]

Yeah. I am not reallly sure why this is happening either. Actually I am a bit puzzled here. Seems that one of those happened AGAIN! And Again with 60 seconds (which I was sure should be changed to 120 now). So I am a bit lost here :)

https://github.com/apache/airflow/pull/17486/checks?check_run_id=3269777720#step:6:10094

[potiuk]

It's only the "test_airflow_context" that has problem. I limited the timeout to that test only and let's see. I am not sure why applying timeout on the class level did not work - maybe it's not supported well.

[potiuk]

Same here: https://github.com/apache/airflow/pull/17458/checks?check_run_id=3269810558 reallly puzzling !

[potiuk]

Ah right. the execution_timeout is indeed only applicable on function-level. So It had no chance to work for class.

Still - I am not sure if it's the virtualenv creation, but when i test it locally this "test_airflow_context" takes ~20 seconds to run, so I can imagine easily when you run several tests in parallell something might get into contention and make it works for quite a bit longer than 20 seconds. I think in this case it is pickling the whole context that takes that much time. It looks like this is the only one test case that has both:

use_dill=True, system_site_packages=True

I do not know some intrinsic details of what's going on in this case, but it sounds plausible that this combination might work much slower.

[potiuk]

Yeah. Seems like we save a lot of context in a serializable form in a file - including all the airflow system classes which come via dag /macros etc. etc. and restore them when we run the task. That might take a long time when dill is used I guess.

[potiuk]

I updated the description in PR to reflect this and will update it in the commit if it will work now (I hope it will)..

[potiuk]

Ehhh. Seems that we also needed to apply --timeout-order. Default order of --pytest-timeout is that commandline overrides markers (?). Pretty counter-intuitive. https://pytest-timeouts.readthedocs.io/en/latest/usage/#timeout-order

So whatever we applied as marker, was not effective because the command-line 60 overrode it (!).