Dear maintainer(s),

I looked at the results of the autopkgtest of your package. I noticed
that it regularly fails. The failure mode seems to vary, I pasted two
failures from three logs below.

Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.

Don't hesitate to reach out if you need help and some more information
from our infrastructure.

Paul

https://ci.debian.net/packages/e/electrum/unstable/amd64/74489351/

398s >       self.assertIn(swap._funding_prevout, batch.batch_inputs)
398s E       AssertionError:
<TxOutpoint("cd34f4230c63c19eb97508ac3d607907509f7c94123411602daf924a56f7c33a:0")>
not found in {}
398s
398s tests/test_submarine_swaps.py:680: AssertionError


https://ci.debian.net/packages/e/electrum/unstable/loong64/74488289/

586s >           assert srv_sess.got_disconnected.is_set()
586s E           assert False
586s E            +  where False = is_set()
586s E            +    where is_set = <asyncio.locks.Event object at
0x7fffecd3eab0 [unset]>.is_set
586s E            +      where <asyncio.locks.Event object at
0x7fffecd3eab0 [unset]> = <tests.toyserver.toyserver.ToyServerSession
object at 0x7fffed22a490>.got_disconnected
586s
586s tests/test_interface.py:191: AssertionError


https://ci.debian.net/packages/e/electrum/testing/i386/74487101/

436s >           assert srv_sess.got_disconnected.is_set()
436s E           assert False
436s E            +  where False = is_set()
436s E            +    where is_set = <asyncio.locks.Event object at
0xf4417d20 [unset]>.is_set
436s E            +      where <asyncio.locks.Event object at 0xf4417d20
[unset]> = <tests.toyserver.toyserver.ToyServerSession object at
0xf4883ea0>.got_disconnected
436s
436s tests/test_interface.py:191: AssertionError

I have never been able to replicate these autopkgtest failures locally (sbuild
unshare chroot), but I have seen them on debci and Salsa CI.  Is there anything
about the debci autopkgtest environment (possibly a resource restriction) that
might cause them to fail?

When doing so, I would see inconsistent failures on Salsa CI.  With this release I switched
the tests to be run sequentially, and the Salsa CI failures disappeared.  This would usually
lead me to believe that it might be a problem with either CPU constraints (causing the
tests to timeout when run in parallel) or RAM constraints (causing a tests to fail if the RAM
is exhaused).

I do not see any OOM errors in the logs.  When running the tests locally, no part of the
entire build-test process consumes more than 6GB of RAM.  During build CPU usage can
consume a single core entirely, but during the autopkgtests CPU usage doesn’t rise above
25% of a single core.  So, I have a hard time imagining either of those being the problem.

Hi

Several of our hosts have a lot of resources, see [1]. Maybe it's excess
of either CPUs or RAM that cause parallelism to interfere. Although then
I wouldn't expect as much failure on i386, which are reasonably sized
VMs. Another idea would be that the load on these systems might be
higher than when you try to test in isolation.

I assume you also test locally with lxc or incus as those are the
backends we used/use on ci.d.n and most, if not all, restrictions come
from used that.

Paul

[1] https://ci.debian.net/inventory/

Hi,


I forgot to mention, we (ci.d.n admins) can give you access to a testbed
on our infrastructure where the test just ran for you to debug if that
helps. As we need to be on-line during the exercise, please contact us
on #debci on oftc and we can arrange it.

Paul