If a version update fails due to a rate limit error, you can't update the version through the UI

[coverbeck]

Describe the bug
See discussion at https://discuss.dockstore.org/t/message-this-version-has-no-files-of-this-type-upon-refresh-but-valid-file-exists/7679, but it looks like what happened was (implementer should verify):

1. Non .dockstore.yml workflow
2. User clicked button to refresh the workflow
3. A GitHub rate limit error happened while processing the refresh. It's unclear why; my theory is that they tried to refresh several times.
4. We wrote out the commit of the version processed, but no source file content (because of the error fetching the content due to the GitHub rate limit)
5. After the rate limit was "restored", the user tried refreshing again, but because the webservice saw it had already processed the commit, it skipped and didn't read anything from GitHub; file stayed with no content.
6. The user was able to refresh the version using the hardRefresh=true query parameter

To Reproduce
Steps to reproduce the behavior:
See Discourse topic and description

Expected behavior
Ideas:

1. Don't write out the commit if we get a rate limit error; have better indications in general for this error case.
2. Expose hardRefresh query parameter in the UI. Perhaps only for versions, and not the workflow, as it can result in a ton of API requests for some workflows.

Additional context
[Domain] - https://dockstore.org

Webservice

• 1.14.2

UI

• 2.11.1

Compose Setup

• 1.14

Deploy

• 1.14.1

┆Issue is synchronized with this Jira Story
┆Fix Versions: Dockstore 2.X
┆Issue Number: DOCK-2479
┆Sprint: Backlog
┆Issue Type: Story

[coverbeck]

Given that this deprecated path for registering workflows, it may not be worth the effort. But we should also make sure this doesn't happen in the .dockstore.yml path -- even though we haven't had any rate limit errors there yet, it could happen eventually.