FerrLabs/FerrFlow-Cloud#790 pinned FerrLabs/.github to b6c0dc1. It was opened on 2026-08-09, carried a single commit dated 2026-08-09, and was merged on 2026-08-29. By then the pin was 70 commits behind .github main, and at that revision reusable-ci-rust.yml calls reusable-sonarqube-scan.yml at e01fb75f, a third revision again, so the pin lands on a mixture of repository states rather than any single one.
Merging it startup-failed CI on FerrFlow-Cloud main. No job runs, so none of the four required checks reports, so every open PR in the repo went to BLOCKED with nothing to re-run and no way to recover from the PR side. Fixed in FerrLabs/FerrFlow-Cloud#867 by moving to 62a681d7.
Two things in the preset are worth looking at, and I could not tell from outside which one actually caused it.
Rule 6 in default.json gives this group schedule: at any time, minimumReleaseAge: 0, internalChecksFilter: none and automerge: true. The intent reads as "land these the moment checks pass", and it works: FerrFlow-Cloud#655, #744 and #763 were all opened and merged the same day by the bot. #790 is the one that did not, and it was eventually merged by a human, twenty days late. Something stopped automerge on that branch and nothing said so.
Renovate also left the branch content frozen at its 2026-08-09 commit for those twenty days, despite rebaseWhen: behind-base-branch and recreateWhen: always. A digest PR that goes stale is not merely late, it is wrong: merging it writes a pin that was correct three weeks ago into a repository whose callers have moved on.
dependencyDashboard: false is what made this invisible. There is no surface where a stuck Renovate PR shows up, so a PR whose automerge quietly stopped just sits there looking like a normal open PR until somebody merges it by hand.
What would have prevented the outage: a digest PR that cannot merge promptly should refresh its pin or be closed, not wait. Whether that is best done by turning the dashboard back on for visibility, by narrowing what the group is allowed to pin, or by finding and fixing the automerge stall, I don't know, and picking between them wants someone with the Renovate logs.
Worth noting this is not the .github self-reference loop from #249. That rule is in this repo's own renovate.json and is correctly scoped: consumers resolve the preset from default.json, so they still track their FerrLabs/.github pin, which is the intended behaviour.
FerrLabs/FerrFlow-Cloud#790 pinned
FerrLabs/.githubtob6c0dc1. It was opened on 2026-08-09, carried a single commit dated 2026-08-09, and was merged on 2026-08-29. By then the pin was 70 commits behind.githubmain, and at that revisionreusable-ci-rust.ymlcallsreusable-sonarqube-scan.ymlate01fb75f, a third revision again, so the pin lands on a mixture of repository states rather than any single one.Merging it startup-failed CI on FerrFlow-Cloud main. No job runs, so none of the four required checks reports, so every open PR in the repo went to BLOCKED with nothing to re-run and no way to recover from the PR side. Fixed in FerrLabs/FerrFlow-Cloud#867 by moving to
62a681d7.Two things in the preset are worth looking at, and I could not tell from outside which one actually caused it.
Rule 6 in
default.jsongives this groupschedule: at any time,minimumReleaseAge: 0,internalChecksFilter: noneandautomerge: true. The intent reads as "land these the moment checks pass", and it works: FerrFlow-Cloud#655, #744 and #763 were all opened and merged the same day by the bot. #790 is the one that did not, and it was eventually merged by a human, twenty days late. Something stopped automerge on that branch and nothing said so.Renovate also left the branch content frozen at its 2026-08-09 commit for those twenty days, despite
rebaseWhen: behind-base-branchandrecreateWhen: always. A digest PR that goes stale is not merely late, it is wrong: merging it writes a pin that was correct three weeks ago into a repository whose callers have moved on.dependencyDashboard: falseis what made this invisible. There is no surface where a stuck Renovate PR shows up, so a PR whose automerge quietly stopped just sits there looking like a normal open PR until somebody merges it by hand.What would have prevented the outage: a digest PR that cannot merge promptly should refresh its pin or be closed, not wait. Whether that is best done by turning the dashboard back on for visibility, by narrowing what the group is allowed to pin, or by finding and fixing the automerge stall, I don't know, and picking between them wants someone with the Renovate logs.
Worth noting this is not the
.githubself-reference loop from #249. That rule is in this repo's ownrenovate.jsonand is correctly scoped: consumers resolve the preset fromdefault.json, so they still track theirFerrLabs/.githubpin, which is the intended behaviour.