Closed Bug 1701150 Opened 5 years ago Closed 5 years ago

Intermittent comm/mail/test/browser/openpgp/composition/browser_composeEncrypted.js | 2 recipient key statuses should be displayed - 0 == 2 - testEncryptedOneRecipientKeyNotAvailableMessageComposition/keyStatusDialog< :: line 439

Categories

(MailNews Core :: Security: OpenPGP, defect, P5)

defect

Tracking

(thunderbird_esr78 unaffected)

RESOLVED FIXED
89 Branch
Tracking Status
thunderbird_esr78 --- unaffected

People

(Reporter: intermittent-bug-filer, Assigned: lasana)

Details

(Keywords: intermittent-failure)

Attachments

(1 file)

Regression caused by bug 1693133 ?

Adding Lasana who wrote this test. Do you have an idea what might go wrong now?

Not sure if it's the same or not but a very similar failure just showed up on Linux.

Assignee: nobody → lasana

I think I found the culprit behind this, maybe. Occasionally the callback here:
https://searchfox.org/comm-central/source/mail/test/browser/openpgp/composition/browser_composeEncrypted.js#436
is being called before the key status dialog is finished.

After some debugging I traced the preemptive execution to this point:
https://searchfox.org/comm-central/source/mail/extensions/openpgp/content/modules/sqliteDb.jsm#90

To me

await conn
        .execute(
          "select decision from acceptance_decision where fpr = :fpr",
          qObj
        )
        .then(result => {
          if (result.length) {
            rv.fingerprintAcceptance = result[0].getResultByName("decision");
          }
        });

is the same as

let promise = conn.execute(
          "select decision from acceptance_decision where fpr = :fpr",
          qObj
        );

await  promise
        .then(result => {
          if (result.length) {
            rv.fingerprintAcceptance = result[0].getResultByName("decision");
          }
        });

Which is to say the creation of the promise is not awaited on, potentially opening up room for racy conditions. That said, the test still fails if that is cleaned up. The key status dialog is populated asynchronously in an onload handler in any case so I'll just change the assertions to TestUtils.waitForCondition.

I should mention I could not reproduce this via an artifact build locally. Only when I did a fresh rebuild. Maybe something change in the lower layers recently.

Status: NEW → ASSIGNED

(In reply to Lasana Murray from comment #6)
I don't see any difference there?

Target Milestone: --- → 89 Branch

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/2c85f0685155
Wait for key statuses to be populated in compose encrypted test. r=mkmelin

Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED

(In reply to Magnus Melin [:mkmelin] from comment #9)

(In reply to Lasana Murray from comment #6)
I don't see any difference there?

I'm unsure of the semantics myself, it certainly is odd syntax. May be worth keeping an eye on if things get start running out of order.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: