Lock file PR not getting updated if already open (unless "rebase" checkbox ticked)

[dominykas]

What Renovate type, platform and version are you using?

Self-hosted

Describe the bug

When a "lock file maintenance" PR is already it open, it does not get updated even if there are new items to be updated in there.

If the PR has If you want to rebase/retry this PR, check this box ticked, then the update does happen as expected.

This has regressed quite a while ago (several months?), I just didn't have time to raise the bug until now...

Relevant debug logs

DEBUG: manager.getUpdatedPackageFiles() reuseExistinbranch=true (repository=my-private-org/my-private-repo, branch=renovate/lock-file-maintenance)
DEBUG: No package files need updating (repository=my-private-org/my-private-repo, branch=renovate/lock-file-maintenance)
DEBUG: Getting updated lock files (repository=my-private-org/my-private-repo, branch=renovate/lock-file-maintenance)
DEBUG: Skipping lockFileMaintenance update (repository=my-private-org/my-private-repo, branch=renovate/lock-file-maintenance)
DEBUG: No updated lock files in branch (repository=my-private-org/my-private-repo, branch=renovate/lock-file-maintenance)
DEBUG: No files to commit (repository=my-private-org/my-private-repo, branch=renovate/lock-file-maintenance)
DEBUG: Checking if we can automerge branch (repository=my-private-org/my-private-repo, branch=renovate/lock-file-maintenance)
DEBUG: mergeStatus=no automerge (repository=my-private-org/my-private-repo, branch=renovate/lock-file-maintenance)
DEBUG: Ensuring PR (repository=my-private-org/my-private-repo, branch=renovate/lock-file-maintenance)
DEBUG: There are 0 errors and 0 warnings (repository=my-private-org/my-private-repo, branch=renovate/lock-file-maintenance)
DEBUG: getBranchPr(renovate/lock-file-maintenance) (repository=my-private-org/my-private-repo, branch=renovate/lock-file-maintenance)
DEBUG: findPr(renovate/lock-file-maintenance, undefined, open) (repository=my-private-org/my-private-repo, branch=renovate/lock-file-maintenance)
DEBUG: Found PR #610 (repository=my-private-org/my-private-repo, branch=renovate/lock-file-maintenance)
DEBUG: Returning from graphql open PR list (repository=my-private-org/my-private-repo, branch=renovate/lock-file-maintenance)
DEBUG: Found existing PR (repository=my-private-org/my-private-repo, branch=renovate/lock-file-maintenance)
DEBUG: Processing existing PR (repository=my-private-org/my-private-repo, branch=renovate/lock-file-maintenance)
DEBUG: Pull Request #610 does not need updating (repository=my-private-org/my-private-repo, branch=renovate/lock-file-maintenance)

When the "rebase" checkbox is ticked, the following line is also present:

DEBUG: Ensuring npm-shrinkwrap.json is removed (repository=my-private-org/my-private-repo, branch=renovate/lock-file-maintenance)

Have you created a minimal reproduction repository?

Please read the minimal reproductions documentation to learn how to make a good minimal reproduction repository.

• This is a really small bug, it does not need a reproduction (think small typo)
• I have provided a minimal reproduction repository
• I don't have time for that, but it happens in a public repository I have linked to
• I don't have time for that, and cannot share my private repository
• The nature of this bug means it's impossible to reproduce publicly

Additional context

Creating a repro case is a bit involved, but I can possibly do it if this does not have enough information.

We have the following in the config:

    lockFileMaintenance: {
        enabled: true,
        schedule: 'at any time'
    }

[viceice]

Renovate only rebase when pr is conflicted (or it detects the must-up-to-date branch protection).
It will also rebase if automerge is enabled and the branch is behind base branch.

See rebaseWhen

[dominykas]

This is not about rebasing - it does not need to rebase - it needs to update the lock file, but it does not update the lock file, unless the "rebase" option is ticked.

It does update e.g. the package.json without the "rebase" option ticked.

[rarkins]

Renovate doesn't perform lock file maintenance non-stop as it would be too inefficient. To know if it needs updating, it would have to do a full install every single run, which is not a good idea. The current behavior is therefore by design.

[HonkingGoose]

Marking this as the answer, so that it's clear this discussion is "resolved".

See issue #9253 as a follow up to this discussion.
That issue is a request for the following feature:

An option to refresh lock file update PRs when they get stale

[dominykas]

Renovate doesn't perform lock file maintenance non-stop as it would be too inefficient.

That's fine - that's by configuration - it makes perfect sense to not do it on every run. However if the PR is open, it does not perform it at all (even if the scheduled date has been hit, or if you set up to perform it every time. I would expect the PR to get updated (on schedule)?

[rarkins]

I can't say for sure if it changed a few months ago, but it was always the intention since lock file maintenance was created not to "churn" it every run. If it was different for a while then it was unintentional and undesirable.

Having some type of time threshold in days before retrying could be a good idea, although it's not as simple as a single if/then addition - the logic to refresh it needs to be added too, also keeping in mind that people sometimes combine lock file maintenance in a group, which was not the original intention of it!

[dominykas]

OK, got it, thanks

[rarkins]

If you wish, please create a feature request issue proposing a new config-option, measured in days, which specifies the minimum time to wait before retrying lock file maintenance PRs.

[dominykas]

Created #9253.

Can discussions be closed or smth on GH?

[HonkingGoose]

Can discussions be closed or smth on GH?

I don't think that's a possibility yet, at least not from what I can find in the GitHub documentation... 😄
Discussions is still a bit of a beta feature as of now, so maybe they'll add this feature later on.