connection often times out on `test_download` and `test_get_download_normalization_process_handler`
还没有人认领这个 Issue。
评估
- 难度
- 3/5
- 预计耗时
- 1-2 天
- 新手友好度
- 35/100
- Issue 类型
- 缺陷
- 描述清晰度
- 基本清楚
- 活跃度
- 停滞
- 技术栈
- python
- 领域
- networking, testing-qa
调研方向
从 labcontrol/gui/testing.py 第 71 行的 timeout 开始,使用所引用的 Travis build 重现 test_download 和 test_get_download_normalization_process_handler 中的失败。比较增加 timeout 或在测试中添加重试是否能够解决间歇性网络故障;完成的标准是两个下载测试都能可靠通过,同时保留现有的响应断言。
由索引模型根据 Issue 内容生成。
描述
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
- 主要语言
- Python
- 星标
- 2
- 派生
- 15
- PR 合并指标
- 30 天内没有已合并 PR
环境准备
我们还没有检查这个项目的环境配置文件。先看它的 README,通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
biocore/LabControl 的其他 Issue
-
bug front-end question
难度 4/5 3-5 天 新手友好度 30/100
biocore/LabControl#594 ·
-
front-end question
难度 5/5 一周以上 新手友好度 35/100
biocore/LabControl#593 ·
-
Cache list of active samples when the active study is changed in the plating interface可能重新可做 @fedarko 于 2573 天前认领,目前没有进行中的 PR。 未关闭front-end
biocore/LabControl#592 · 已指派 1 人 ·
-
code refactor front-end
难度 5/5 一周以上 新手友好度 25/100
biocore/LabControl#591 ·
-
priority:low
难度 3/5 1-2 天 新手友好度 20/100
biocore/LabControl#590 ·
查看 biocore/LabControl 的全部 Issue
相似的 Issue
-
needs triage
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 2 天内回复
-
难度 2/5 1-3 小时 新手友好度 82/100
openvinotoolkit/openvino_notebooks#3665 ·
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 86/100
维护者通常 1 天内回复
-
docs
难度 2/5 1-3 小时 新手友好度 88/100
维护者通常 1 天内回复
-
benchmark-gap
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复