What Renovate type are you using?
We're using the hosted app on this repo
Describe the bug
About a week ago, a few of our open renovate bot PRs (see list below) started giving 500 errors, and eventually stopped sending PRs altogether. We filed an issue with GitHub, who let us know that the PR's upstream head ref repository was recently deleted, which is why those open PRs are throwing errors. This is definitely not something that we wanted or was done intentionally, nor do we have any way of knowing what caused this deletion. Interestingly, I did see one PR this week come in from renovate, and it came from a repo that was named similarly to our fork, but with a "-1" on the end. Other than that, it's been quiet from renovate this week, which is extremely unusual, and I suspect is because the original forked repo no longer exists.
PRs throwing errors
Relevant debug logs
Unfortunately, because we're not self hosting and this is a case where we think our repo was somehow deleted, we have no relevant logs.
To Reproduce
Please see the list above of the PRs affected, and the linked PR that came from the mystery "-1" fork
Additional context
I did have one of my colleagues "turn it off and turn it on again", which had no change. If there's anything else I can try to help debug, please let me know, I appreciate any help!
Forking Renovate has a "recovery" mechanism to delete and recreate its fork if the existing fork cannot be updated, so that maybe explains what you saw. It was intended as something beneficial but maybe the impact of losing/closing existing PRs is it worth it. If you rename any existing failed PRs (eg with "-old") suffix then you should allow replacements to be created in their place.
Quick question: has anyone ever git force pushed to the default branch (eg master) of your repo?
The linked PR will change Renovate behavior to never delete the forks and instead log an error. This will mean manual intervention is usually necessary but also mean that forks won't "disappear" from any existing PRs.
:tada: This issue has been resolved in version 22.24.4 :tada:
The release is available on:
22.24.4Your semantic-release bot :package::rocket:
Hey! sorry for slow reply. So glad to see the new version release! For the record and anyone else searching, afaik, no known force pushes to master, at least in the past couple of years - we have the the setting checked that doesn't allow that. Pre 2018 though, not sure - this repo has been around for awhile and has a LOT of contributors. Thanks for such a timely reply and for the fix - I just saw a PR from our bot a few minutes ago!
Thanks for the confirmation. Going forward, the forks we use for your repos will no longer be automatically removed and replaced in cases where GitHub's API rejects our requests to patch our fork to be up to date with the upstream repo. Instead we'll look into any problems manually and decide from there.
Thanks again @rarkins ! Another related question as we begin to recover and utilize our new fork - it seems like our Dependency Dashboard points to the old fork still - is there a recommendation for how to update it to point to the new fork? Close it? Update our renovate.json to not use the dashboard and then re-enable it? Something else clever?
There's nothing to lose by closing the Dashboard and letting Renovate create a new one, but I'm not sure that would change anything. When you say it "points to the old fork" - what specifically do you mean? It looks like maybe the Closed/Ignored PR was from that fork but the open ones seem ok to me
Ha - from the time I wrote that comment to now, it seemed to refresh! Looks like i just needed to be patient with the GitHub APIs. Thanks again for all of your help!