Should renovate check for existing non-open PR when changing version in lower version PR?

[snuggie12]

Tell us more.

We experienced the following scenario:

• manager is kustomize
• data source is helm chart version
• Currently the instance of the chart is on version 0.0.1
• The chart itself has a version 0.0.2 and 0.0.3
• Both versions have not met minimum release age
• auto merging is enabled
• 0.0.3 contains a regression
• Using the dependency dashboard, 0.0.3 is created as a PR and instantly closed. I believe the logic was to prevent it from being automerged
• On the next cycle, a PR is created for 0.0.2. I'm not 100% sure, but I guess it's just a coincidence that it met minimum release age?
• However, there's an automerge schedule and it's not in the window currently (this is on a Friday afternoon.)
• Several cycles on this repo happen and nothing happens since it won't automerge until Monday
• Somehow on Sunday the PR changes to upgrading 0.0.3
• Monday it automerges with the regression

No one was working on Sunday and I've tried to figure out in the logs why this even happened, but it seems like when it thought it should change the PR from 2 to 3 it should first check that there are no non-open PRs like it does for other actions.

Not sure if this is a bug or a new feature request or if we're just missing a configuration but the timing is the weirdest part. My best guess is that was the minimum release age?

[rarkins]

The existence of a previously closed PR will prevent an identical one from being created in its place, but not prevent a different PR being updated to match, like in your case. I don't think there's any easy or elegant way to prevent what you experienced, and because it's such an unusual edge case then we would be unlikely to try to code a solution for it. Ultimately you should avoid automerging if either (a) the source package is unreliable (and a 0.0.x is about as unreliable as you can get from a versioning perspective), or (b) you don't have tests to cover yourself from breakages.

[snuggie12]

Thank you @rarkins for the explanation. A couple of final things:

• Not that it matters, but I only gave those version numbers as an example.
• Was my assumption correct on the reason for when it happened? Are there other possible reasons for why 48 or so hours passed?

[rarkins]

Your assumption is the most likely explanation

[snuggie12]

Yeah, I went back and looked and all the timings lined up.

After re-explaining this situation to others I completely agree it's pretty niche. The minimum release age, there being two versions and the exact time gap between them, the weekend, etc. Really all had to align in a special way. Had the one version released like 6 hours earlier this wouldn't have happened.