fix(workers/repository): skip pending-version check when re-extracted dep lacks resolved version

[mado-m]

Changes

checkForPendingVersions (introduced in #41629) currently throws WORKER_FILE_UPDATE_FAILED when the re-extracted dep has none of lockedVersion, newVersion, currentVersion, or currentValue populated. That throw aborts the entire getUpdatedPackageFiles flow for a single dep we cannot verify — which is disproportionate to the intent of the check (flag artifact updates that introduced a pending version).

This PR demotes the abort to warn-and-continue: if the resolved version for a single dep cannot be determined, the pending-version check is skipped for that dep only and the rest of the update proceeds.

 if (!resolvedVersion) {
-  logger.error(
-    { ..., depName, newVersion: resolvedVersion },
-    `No new version found for '${depName}' after updating '${packageFileName}'`,
-  );
-  throw new Error(WORKER_FILE_UPDATE_FAILED);
+  logger.warn(
+    { ..., depName },
+    `Could not determine resolved version for '${depName}' after updating '${packageFileName}'; skipping pending-version check`,
+  );
+  continue;
 }

Concrete scenario observed

Triggered with minimumReleaseAge: '7 days' + the terraform manager / terraform-provider datasource. The upgrade object Renovate built for DataDog/datadog at the cooldown boundary:

{
  "depName": "datadog",
  "datasource": "terraform-provider",
  "packageName": "datadog/datadog",
  "currentValue": "4.6.0",
  "currentVersion": "4.6.0",
  "updates": [{
    "newVersion": "4.7.0",
    "newVersionAgeInDays": 7,
    "pendingVersions": ["4.8.0", "4.9.0"]
  }]
}

The relevant log sequence:

DEBUG: terraform.updateArtifacts(main.tf)
DEBUG: Found 1 provider deps
DEBUG: Pinning constraint for "datadog/datadog" to "4.7.0"
DEBUG: Creating hashes for datadog/datadog@4.7.0 (https://registry.terraform.io)
DEBUG: Writing updates to .terraform.lock.hcl
ERROR: No new version found for 'datadog' after updating 'main.tf'
       newVersion: undefined
WARN : Error updating branch: update failure
Error: The process '/usr/bin/docker' failed with exit code 1

The .tf file is successfully rewritten 4.6.0 → 4.7.0 — the Contents updated debug log fires earlier in the same run for the same file, and the lockfile artifact write begins. Then checkForPendingVersions re-extracts the updated content and, somehow, the re-extracted dep object surfaces no lockedVersion / newVersion / currentVersion / currentValue, so resolvedVersion is undefined and the function throws.

From the function's own perspective this is a false negative: it cannot determine whether 4.7.0 falls into pendingVersions: ["4.8.0", "4.9.0"] (it doesn't), but instead of skipping the check it aborts the whole worker. The actual package-file update succeeded; what failed is only this optional verification pass.

Why warn-and-continue is the right behavior here

The check exists to surface a soft warning when an artifact update has resolved to a pending version. If the four version fields on the re-extracted dep are all undefined, the function simply cannot perform the comparison for that dep. The remaining deps in the same file can still be verified normally, and a logger.warn keeps the skip visible without taking down the update.

Investigating why the terraform re-extract surfaces an unpopulated dep here is out of scope — the goal of this PR is just to make checkForPendingVersions resilient so a single unverifiable dep does not abort the whole flow.

The existing it('rejects when an updated dependency has no new version', ...) test is updated to reflect the new warn-and-continue behavior.

Context

Please select one of the following:

• This closes an existing Issue, Closes: #
• This doesn't close an Issue, but I accept the risk that this PR may be closed if maintainers disagree with its opening or implementation

AI assistance disclosure

• Yes — substantive assistance (AI-generated non‑trivial portions of code, tests, or documentation).

Used Claude (Anthropic) to locate the throw site and draft the code/test change. Reviewed and verified locally.

Documentation (please check one with an [x])

• I have updated the documentation, or
• No documentation update is required

How I've tested my work (please select one)

I have verified these changes via:

• Newly added/modified unit tests

pnpm vitest run lib/workers/repository/update/branch/get-updated.spec.ts → all 58 tests pass.

[cla-assistant]

All committers have signed the CLA.

[mado-m]

@viceice friendly ping — CLA is now signed. Would appreciate a review when you have a moment. The change is intentionally small (≈8 lines + an updated test) and aimed at making checkForPendingVersions resilient to a single unverifiable dep rather than aborting the whole getUpdatedPackageFiles flow. Happy to adjust scope/wording if a different direction is preferred. Thanks!

[mado-m]

@viceice @RahulGautamSingh @jamietanna sorry for the extra ping.

This PR has been waiting for review for a few days. The change is intentionally small: it only makes checkForPendingVersions skip a pending-version check when a re-extracted dependency has no resolved version, instead of aborting the whole getUpdatedPackageFiles flow.

Most checks are passing, but license/cla still appears to be pending even though I believe I have completed the CLA. Could someone please help recheck the CLA status or let me know if there is anything else I need to do?

Once that blocker is cleared, I would appreciate a review or guidance on whether this is the right direction. Thanks!

[github-actions]

Hi there,

This is intended as a polite, automated request that users avoid @ mentioning repository maintainers like @viceice. Doing so causes annoying mobile notifications and makes it harder to maintain this repository.

We know it might be common elsewhere but we participate in hundreds of discussions a week and would need to turn off GitHub mobile notifications if we were mentioned in every one.

As a general rule, we will read and respond to all discussions in this repository, so there is no need to mention us.

Thanks, the Renovate team

[jamietanna]

It's possible for you to re-check the CLA status by following the link ☝🏽

Don't ping maintainers/collaborators on the repo. We're generally working on things as they come in and/or in priority that we determine

(I appreciate that this has waited for a bit, and that it may be blocking you, but we do also have many other PRs to look at, and we don't want to folks to think that if they @-mention us they get prioritised)

[mado-m]

CLA is now passing. Based on the discussion above, I'll leave the existing dynamic WARN message unchanged as it is outside the scope of this PR.

[mado-m]

Per the discussion on the get-updated.ts:605 thread, the dynamic WARN message was agreed to stay as-is (out of scope for this PR). Could the open Changes requested review be re-evaluated when convenient? Thanks!

[RahulGautamSingh]

lgtm

[mado-m]

Just checking in on this. The latest feedback has been addressed/clarified and CI is green; is there anything else needed from my side to move this forward?

[github-actions]

🎉 This PR is included in version 43.204.1 🎉

The release is available on:

• GitHub release
• 43.204.1

Your semantic-release bot 📦🚀