[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1070790: fwupd: flaky autopkgtest on arm64: fwupd/fwupdmgr-p2p.test: The connection is closed



Source: fwupd
Version: 1.9.19-1
Severity: important
User: debian-ci@lists.debian.org
Usertags: flaky
X-Debbugs-Cc: debian-ci@lists.debian.org
Control: affects -1 + src:glib2.0
Control: found -1 1.9.16-1

fwupd appears to have a "flaky" autopkgtest: that is, an autopkgtest
that usually passes, but is not reliable.

This means that when packages that are depended on by the test suite, such
as the glib2.0 security fix currently in unstable, are trying to migrate
to testing, the test will randomly pass or fail, causing those packages
to be detected as having caused a regression when in fact they have not.

For example see
https://ci.debian.net/packages/f/fwupd/testing/arm64/46456704/
(while testing a new glib2.0),
https://ci.debian.net/packages/f/fwupd/testing/arm64/46242873/
(while testing a new sqlite) and
https://ci.debian.net/packages/f/fwupd/testing/s390x/46251882/
(while testing a new fwupd).

I suspect this is a race condition in the test, rather than a result of
a change immediately before one of those runs. This appears to happen
rarely on arm64, very rarely on s390x, and in practice never on amd64 -
which again makes me think that timing is involved.

"The connection is closed" is the error message used by GLib's GDBus when
a D-Bus connection is closed with D-Bus method calls still "in-flight",
or when the D-Bus connection is flushed or closed or an attempt is made
to send a message after it is already closed.

Perhaps this test closes a D-Bus connection during teardown, and there is
a race condition in which it might or might not have finished doing other
things on that connection before that point?

If this test or this feature cannot be made fully reliable, one option
is to skip it in debian/tests/ci, and re-run it in a separate
autopkgtest script that is marked as "Restrictions: flaky". A few GNOME
packages use the convention that flaky tests are marked like this:

    @unittest.skipIf('DEB_ALLOW_FLAKY_TESTS' not in os.environ, 'https://bugs.debian.org/123456')
    def test_something_flaky(...):
        ...

(or the equivalent in other languages) so that they are normally skipped,
but we can force them to be run (to assess whether they are still a
problem!) by using "export DEB_ALLOW_FLAKY_TESTS=1".

    smcv


Reply to: