Add retry logic when fetching addons, and save error to cache for user investigation - #493
Add retry logic when fetching addons, and save error to cache for user investigation#493MarcBresson wants to merge 11 commits into
Conversation
A crash during the 6-hourly cache rebuild could permanently drop an addon's cached package.xml/icon for that cycle (since the existing good clone was deleted beforehand). Retry git commands a few times before giving up. If an update ultimately fails, keep the existing good clone. Also retry addons that failed on the previous run first, so a rate-limit-driven failure doesn't always strand the same addons at the tail of a fixed processing order.
for more information, see https://pre-commit.ci
|
sorry for the format issue, ruff is runing when I save files, and it seems like I forgot to undo changes from the test file |
|
Initially I also added an extra step that tried recloning the repo when there was a fetch failure, but I figured it would be redundant so I removed it in the third commit |
|
also, I did not use logger because the file was using print statements, but I don't know if there is a specific internal policy against the use of logger. If you want, I can replace prints with logger calls |
…aving files untouched
chennes
left a comment
There was a problem hiding this comment.
This looks mostly good -- could you please rebuild the changes without the ruff formatting, and address the two inline code comments? Thanks!
| # In the event of basically ANY error, delete the original and re-clone. | ||
| print(e) | ||
| print("Deleting and re-cloning the original repo") | ||
| os.chdir(old_dir) | ||
| utils.rmdir(os.path.join(old_dir, name)) | ||
| self.clone_or_update(name, url, branch) |
There was a problem hiding this comment.
I think we should keep the fallback reclone: it wasn't designed for the intermittent failure case you're trying to handle here, but for things like a repo rename, where there is no recovery short of a deletion. If you drop it, then I have to log into the server to manually do this anything someone renames a repo (for example).
There was a problem hiding this comment.
I don't think deleting then recloning would have helped with a git pull problem, since the current path already fetches and hard resets the local repo. Renaming a repository has no effect on git itself, except when the remote URL changes, and even then git follows the redirect. A recent example was my own addon, which was renamed from FreeCad-Grid-Export to CarteGrid including the remote URL, and git followed the 301 and cloned successfully.
That said, looking closer there is a real gap that supports your point. The url passed into fetch_and_reset never actually gets applied to the local clone. So there's no git remote set-url origin anywhere in the update path. If a repo's URL changes in the catalog (rename, ownership transfer, host migration), the existing local clone just keeps fetching from whatever origin was set at the original clone. That works only as long as the old host keeps redirecting to the new one, and GitHub doesn't promise that survives a second rename or the old name getting reused by someone else. A move off GitHub wouldn't redirect at all.
So instead of bringing back delete and reclone, I'd rather fix that directly: add git remote set-url origin {url} before the fetch in fetch_and_reset, so the local remote always stays in sync with whatever the catalog currently says. That covers the case you are describing without reintroducing the part of the old code this PR is meant to remove, which is deleting a working copy before a replacement is confirmed.
I'll push that change very soon :)
this avoids issues in case of a URL change
for more information, see https://pre-commit.ci
caching errors also allows for failed add-on fetches to be retried first
Mitigates #491