Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Retry on failure? #14

Open
dfornika opened this issue Nov 7, 2019 · 2 comments
Open

Retry on failure? #14

dfornika opened this issue Nov 7, 2019 · 2 comments

Comments

@dfornika
Copy link

dfornika commented Nov 7, 2019

I'm working on a galaxy wrapper for this tool. During my testing of the tool wrapper, I've noticed that downloads will sometimes fail. I'd like to have a way to retry the download if it fails.

Would it be more sensible to integrate that directly into the tool, or into the galaxy tool wrapper?

@kblin
Copy link
Owner

kblin commented Nov 7, 2019

I guess this depends on the failure mode. The problem with HTTP downloads is that the "all's good" response from the server arrives in the header, before the actual data comes in. If anything happens to the connection afterwards, it can be difficult for the client side tool to notice.

So I guess the question is "what kind of download failures are you thinking about"?

Also, are you using any of the validation functions?

@dfornika
Copy link
Author

dfornika commented Nov 8, 2019

I wasn't using the validation function when I posted this issue, but I've since updated the galaxy wrapper to run with --extended-validation all enabled. I also added a 5-second delay between downloads. I haven't added any mechanism to retry a failed download to the galaxy wrapper.

Those changes seem to have improved the robustness of the galaxy tool (based an a few quick tests running 6 downloads). I was getting ~3-6 successful downloads before making those changes but got 6 successful downloads on my subsequent test. (I know I should put together a larger test).

But to answer your question, here are a few kinds of download failures I can think of:

  1. The network is degraded/unreliable and no sequence file data is sent.
  2. The network is degraded/unreliable and corrupt or incomplete sequence file data is sent.
  3. The user provides an incorrect accession number so no sequence file data is sent.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants