Preventing Revovate from opening empty merge requests for lockfile maintenance

[datcactus]

How are you running Renovate?

Self-hosted Renovate CLI

Which platform you running Renovate on?

Forgejo

Which version of Renovate are you using?

44.17.1

Please tell us more about your question or problem

When using :maintainLockFilesWeekly, Renovate will occasionally open empty merge requests (no lockfile updates at all). Based on discussion with Jamie, this shouldn't be happening.

The only lockfile that Renovate maintains in my environment is the one for Mise. No errors or warnings are observed during the run, just that the branch was detect (always exists from what I can tell) and that the merge request was created during the scheduled run (* 0-3 * * 1).

Please let me know what I can provide to help debug, if anything. Here's a screenshot of what it looks like in Forgejo. Nothing really out of the ordinary, just an empty merge request. It's unclear to me if it's intended for Renovate to just keep a long-running/immortal merge request that a user can close if they don't want to see, or if this is an unintended behavior.

Logs (if relevant)

Logs

Replace this text with your logs, between the starting and ending triple backticks

[jamietanna]

If you're able to share the full logs from that Renovate run, that'd be appreciated - otherwise the logs that relate to that branch would be best

[datcactus]

Sure, here's the full logs from that run. It's dump from VictoriaLogs so there's some JSON nesting, but the info should all otherwise be there.
full-run-logs.json

[RahulGautamSingh]

This is a nice edge-case 👀 . Looking into it

[RahulGautamSingh]

Explanation: the original lockfile change that created this branch a week ago has been merged in main, leaving the branch with no real diff ... but the branch was never deleted. On the next run Renovate reuses it from cache without verifying content, finds no open PR, and recreateClosed is true for lockFileMaintenance (recreateClosed is true. No need to check for closed PR.), so it opens a fresh, empty PR. That's also why it keeps coming back every week after you close it. The stale branch survives and gets a new PR each schedule window.

Immediate fix: delete the leftover renovate/lock-file-maintenance branch, and turn on "delete branch after merge" in Forgejo. With no stale branch to reuse, Renovate will only create a branch/PR when there's a genuine mise lockfile change.

Is it a bug

Yes. When reuseExistingBranch + cacheFingerprintMatch === 'matched' short-circuit the recompute, nothing confirms the reused branch still differs from base before ensurePr() runs. A stale (already-merged-but-undeleted) branch therefore leads to an empty PR. Github & maybe other platforms IIRC doesn't let one open an empty PR so we didn't detect it.

The reuse path should verify the branch has commits ahead of base before ensuring a PR or we need a mechanism to detect such cases. Need to think on this.

[datcactus]

@RahulGautamSingh thanks for looking into this, and for the advice on branch deletion. I've enabled that and deleted the branch, and will see how it behaves this weekend. Come to think of it this setting makes sense from a cleanliness standpoint, and explains why Renovate would always just clean up its own branches on the next run vs them being deleted immediately on merge.