!buildbot iOS|Android

🤖 New build scheduled with the buildbot fleet by@freakboy3742 for commite8ed3a8 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F131388%2Fmerge

The command will test the builders whose names match following regular expression:iOS|Android

The builders matched are:

• AMD64 Android PR
• aarch64 Android PR
• iOS ARM64 Simulator PR

Hmm, I have some doubts to do this inPdbTestInput. For the majority of tests, this is not needed. Well actually there's only one test that needs it. It might be benign but it just feels weird to me to do it in such a common function. Do you mind just putting it in the actual test?

Hmm, I have some doubts to do this inPdbTestInput. For the majority of tests, this is not needed.

True - but AFAICT, it should be a benign (and fast) cleanup; and it guarantees thatany PDB test that triggers asyncio activity will guarantee that it will be cleaned up automatically, rather than requiring test developers to remember that asyncio cleanup is needed on a per-test basis.

This is especially significant for iOS and Android, because they often end up as the "canary" identifying issues with sequential test execution. There's nothing iOS- or Android-speciifc about this test or test failure, but the iOS and Android buildbots are the only ones that reveal the problem because they're the only test configurations that actually run the tests sequentially. Anything we can do to systematically prevent this class of failure in the future is a win for me because I don't have to chase down buildbot failures that aren't actually caused by iOS- or Android-specific issues.

The reason it feels weird to me is that this piece of code does not belong there.PdbTestInput has a clear semantics and it does not include cleaning up test residues.

I think a better place would betests.addTest(doctest.DocTestSuite(test_pdb, setUp=setUpPdbBackend('monitoring'))) (make sure you updated to the latest main as this was just merged). You can put atearDown there which set the policy toNone - that makes more sense to me.

I think a better place would betests.addTest(doctest.DocTestSuite(test_pdb, setUp=setUpPdbBackend('monitoring')))

Agreed - that makes more sense. I've made that modification.

!buildbot iOS|Android

🤖 New build scheduled with the buildbot fleet by@freakboy3742 for commit6c794e0 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F131388%2Fmerge

The command will test the builders whose names match following regular expression:iOS|Android

The builders matched are:

• AMD64 Android PR
• aarch64 Android PR
• iOS ARM64 Simulator PR

!buildbot iOS

🤖 New build scheduled with the buildbot fleet by@freakboy3742 for commit584aa2b 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F131388%2Fmerge

The command will test the builders whose names match following regular expression:iOS

The builders matched are:

• iOS ARM64 Simulator PR

So we are doing a double insurance here.

@gaogaotiantian Following discussion with@graingert on Discord, I've modified this to use a two-prong approach:

1. Modifying the usage ofasyncio.run() to use the correct "long term" API
2. Retaining the cleanup-on-tearDown so that if a new PDB test forgets to use theloop_factory API, it won't break iOS and Android CI.

@graingert mentioned he has an in-progress PR to fail if theasync.run() API is used in the "non-clean" (i.e., not passing the loop factory) way; until that lands, the 2 prong approach gives some safety that iOS and Android buildbots won't break.