Project

General

Profile

Bug #10501

Bug #10288: Fix newly identified issues to make our test suite more robust and faster

Step 'the "10CC5BC7" key is in the live user's public keyring' is fragile

Added by bertagaz about 4 years ago. Updated about 4 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Test suite
Target version:
Start date:
11/06/2015
Due date:
% Done:

100%

Feature Branch:
kytv/test/9095-robust-seahorse
Type of work:
Code
Blueprint:
Starter:
Affected tool:

Description

We've seen it failing a bit in Jenkins (2 times in September, 3 times in October).

We're not sure of why it fails, so bertagaz will have to dig in the history but it may have been erased with the 1.7 release.
Meanwhile there's been a bump in the retry_tor number that may have helped to workaround it.

One question raised that may help is that currently we fetch the key and check if it's actually been fetched within 2 minutes.
Should we perhaps enforce a limit in the fetch step and cancel the fetch if it's taking too long, then retry?
IIRC that was suggested for the Git tests.

Associated revisions

Revision 9f0692b7
Added by intrigeri about 4 years ago

Merge remote-tracking branch 'kytv/test/9095-robust-seahorse' into stable

Fix-committed: #9095, #10501

History

#2 Updated by bertagaz about 4 years ago

  • Assignee changed from bertagaz to anonym
  • Type of work changed from Research to Discuss

Here are infos about why it fails:

So it seems some retry magics could help, given it seems these are mostly network errors, either from our side but also on the sks keyserver one.

Note that there is always this stop icon in the error window of seahorse, could maybe be helpful to know when to retry?

Assigning to anonym (and adding kytv as watcher), so that you can organize on the next steps (define fix, and update ticket metadatas).

#3 Updated by kytv about 4 years ago

I'm confident that my work on #9095 (& incidentally #9791) will increase general robustness of the entire features/torified_gnupg.feature feature. :)

#4 Updated by kytv about 4 years ago

One of the problems that I discovered is that Seahorse WILL always segfault if there's a network error. It may not segfault until after the close button is clicked, but it will segfault. The way I decided to handle it is to always kill seahorse during the keysyncing step and restart it since we know that it will segfault 100% of the time.

For seahorse, I'm going to assume that if there's a close button on the screen, that's an error. Much of the code I added earlier has been refactored and made less convoluted, partly because I'm using what I learned about ruby since I wrote it, partly because I understand seahorse's failure modes better. :)

I'm also going to kill the gpg binary if key fetching isn't successful within 60 seconds, force a new Tor circuit, then retry.

#5 Updated by kytv about 4 years ago

  • Status changed from Confirmed to In Progress
  • Assignee changed from anonym to kytv
  • Type of work changed from Discuss to Code

I'll take this one since I'm pretty much doing it already in #9095 & #9791.

#6 Updated by kytv about 4 years ago

  • Assignee changed from kytv to anonym
  • % Done changed from 0 to 50
  • QA Check set to Ready for QA
  • Feature Branch set to kytv/test/9095-robust-seahorse

I think this was solved over in #9095.

#7 Updated by bertagaz about 4 years ago

  • Assignee changed from anonym to bertagaz

Want to try this!

#8 Updated by intrigeri about 4 years ago

  • Assignee changed from bertagaz to intrigeri

#9 Updated by intrigeri about 4 years ago

  • Status changed from In Progress to 11
  • % Done changed from 50 to 100

#10 Updated by intrigeri about 4 years ago

  • Assignee deleted (intrigeri)
  • QA Check changed from Ready for QA to Pass

#11 Updated by anonym about 4 years ago

  • Status changed from 11 to Resolved

Also available in: Atom PDF