connection often times out on `test_download` and `test_get_download_normalization_process_handler`
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 35/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- python
- Domain
- networking, testing-qa
Research direction
Start with the timeout at labcontrol/gui/testing.py line 71 and reproduce the failures in test_download and test_get_download_normalization_process_handler using the referenced Travis build. Compare whether increasing the timeout or adding in-test retries addresses the intermittent network failure; done means both download tests pass reliably while retaining their existing response assertions.
Written by the indexing model from the issue text.
Description
Something potentially gnarly, but likely out of the scope of this PR... I ran ea536f3's build twice (this one), and it passed the first time but failed on the two "download" tests (
test_downloadandtest_get_download_normalization_process_handler) when run again.Since these failures were both caused by
AssertionError: Async operation timed out after 10 seconds, it seems like this is an intermittent error due to network problems (???). Not sure how best to handle this, but as a brute-force solution usingtravis_retrywith the python tests might work.
You're right, this has been a recurrent problem I've noticed in the past couple weeks. I think there are a couple things we can do to try to reduce this.
- Increase the
timeoutlimit in the line below:
https://github.com/biocore/LabControl/blob/1427ad163682ff11b1086e0e3b1010ba1a2166ee/labcontrol/gui/testing.py#L71 - add retry functionality within the test, e.g. something like this:
class TestDownloadLibraryPrepShotgunProcessHandler(TestHandlerBase):
def test_download(self):
retries = 0
response = None
while retries < 5:
try:
response = self.get(
'/process/library_prep_shotgun/%d/echo_pick_list' % 1)
except AssertionError:
print("Error downloading on try {}.".format(retries))
else:
break
if response is None:
raise AssertionError("Async operation timed out after maximum number of retries.")
self.assertNotEqual(response.body, '')
self.assertTrue(response.body.startswith(
b'Sample ID\tSource Plate Name\t'))
self.assertEqual(response.headers['Content-Disposition'],
"attachment; filename=2017-10-25_"
"Test_compressed_gDNA_plates_1-4_indices.txt")
Originally posted by @gwarmstrong in https://github.com/biocore/LabControl/pull/585#issuecomment-529705330
- Dominant language
- Python
- Stars
- 2
- Forks
- 15
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from biocore/LabControl
-
bug front-end question
Difficulty 4/5 3-5 days Newbie friendliness 30/100
biocore/LabControl#594 ·
-
front-end question
Difficulty 5/5 Over a week Newbie friendliness 35/100
biocore/LabControl#593 ·
-
front-end
biocore/LabControl#592 · 1 assignee ·
-
code refactor front-end
Difficulty 5/5 Over a week Newbie friendliness 25/100
biocore/LabControl#591 ·
-
priority:low
Difficulty 3/5 1-2 days Newbie friendliness 20/100
biocore/LabControl#590 ·
All issues in biocore/LabControl
Similar issues
-
agent-ready documentation needs-triage
Difficulty 1/5 1-3 hours Newbie friendliness 88/100
-
documentation
Difficulty 1/5 Under an hour Newbie friendliness 91/100
-
workflow-status page template still says reusable workflows are "triggered only by workflow_call:" Open
Difficulty 1/5 Under an hour Newbie friendliness 92/100
-
instance instance add
Difficulty 1/5 Under an hour Newbie friendliness 72/100
searxng/searx-instances#939 · 1 comment ·
-
area-deployment area-integrations triage:bot-seen
Difficulty 2/5 Half a day Newbie friendliness 86/100