Lock file maintenance PR opened outside of scheduled window

[edmorley]

What Renovate type are you using?
Renovate GitHub App

Describe the bug
The webpack-chain repo uses :maintainLockFilesWeekly which has a schedule of "before 3am on Monday", but yet a PR was opened today (Tuesday):
neutrinojs/webpack-chain/pull/101

To Reproduce
Steps to reproduce the behavior:

1. Have a repo that uses :maintainLockFilesWeekly
2. Wait for a PR to be opened on Monday as expected
3. On Tuesday merge that PR (Lock file maintenance neutrinojs/webpack-chain#100)
4. Wait ~2 hours
5. Check if another PR has been opened

Expected behavior
No extra PR outside of the scheduled window.

Additional context
I believe this is the Renovate run that opened the unexpected lockfile maintenance PR:
https://renovatebot.com/dashboard#neutrinojs/webpack-chain/19696257

[rarkins]

Looks like:

Previous lock file maintenance PR was merged but branch not deleted

Renovate detected the branch as existing:

{"msg":"branchExists(renovate/lock-file-maintenance)=true","time":"2018-09-11T16:54:19.928Z"}

Renovate detected schedule correctly:

{"msg":"Does not match schedule because Tuesday is not in Monday","time":"2018-09-11T16:54:23.040Z"}
{"msg":"Package not scheduled","time":"2018-09-11T16:54:23.040Z"}
{"msg":"Branch exists but is not scheduled -- will update if necessary","time":"2018-09-11T16:54:23.040Z"}

Renovate created PR:

{"branch":"renovate/lock-file-maintenance","pr":101,"msg":"PR created","time":"2018-09-11T16:54:25.917Z"}

[renovate-bot]

🎉 This issue has been resolved in version 13.64.17 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[edmorley]

Hi! Thank you for looking into this more.

However if I've understood d19b15b correctly, it means that the lockfile PRs will now never be updated in-between schedule windows, even if the PR is already open? This means that they will be stale, and significantly reduces the usefulness of the lockfile refresh feature for us. For example, if I don't get a chance to review/merge the PR the day it first opens, then when I come to it later, I'll only end up having to manually refresh the lockfile again before I merge it.

Could the new check instead only skip for "not-scheduled" if the PR isn't open? Or if that's not possible, then I'm happy to just have d19b15b reverted, since having to remember to delete the branch (to avoid the issue here) is preferable to open PRs not being refreshed in-between schedule.

Many thanks :-)

[rarkins]

@edmorley thanks for the suggestion. I've improved this logic in 839eeaa

[edmorley]

Amazing - thanks for the change and fast reponse (as always!) :-)