Bug: postUpgradeTasks commits stale content when updateArtifacts() produces duplicate entries for the same file path

[jensholdgaard]

How are you running Renovate?

self-hosted

Which platform you running Renovate on?

Azure

Which version of Renovate are you using?

43.111.1

Please tell us more about your question or problem

Describe the bug

When multiple updateArtifacts() calls produce duplicate entries in the updatedArtifacts array for the same file path, postUpgradeCommandsExecutor only updates the first matching entry (because it uses .find()).

The second (duplicate) entry keeps the stale pre-script content.
Then prepareCommit() writes every entry sequentially (last write wins), so the stale second entry overwrites the correctly updated first one on disk.

Result:

• postUpgradeTasks scripts run correctly and modify files on disk
• Renovate logs "Post-upgrade file saved"
• But the committed branch contains the old (pre-script) content

How duplicates arise (very common in some ecosystems)

In a .NET CPM monorepo this happens naturally:

• nuget.updateArtifacts(Directory.Packages.props) → regenerates ~125 lock files
• nuget.updateArtifacts(global.json) → regenerates the same ~125 lock files
• nuget.updateArtifacts(SomeApp.csproj) → regenerates them again

→ updatedArtifacts ends up with 248 entries for ~125 unique paths (123 paths duplicated).

This pattern also appears in pnpm catalogs, Flutter, and any datasource where multiple package files trigger overlapping artifact regeneration.

Root cause (with code locations)

In lib/workers/repository/update/branch/execute-post-upgrade-commands.ts (v43.111.1):

const existingUpdatedArtifacts = updatedArtifacts.find(
  (ua) => ua.path === relativePath
);
if (existingUpdatedArtifacts?.type === 'addition')
  existingUpdatedArtifacts.contents = existingContent;   // ← only first match updated

In lib/util/git/index.ts → prepareCommit() / commitFilesToBranch:

for (const file of files) {
  await fs.outputFile(filePath, file.contents!);   // last duplicate wins
  await git.add(filePath);
}

(Note: the cosmetic new Set() deduplication only affects the log line, not the actual array.)

Proof

We ran a “marker test”: a post-upgrade script injected a unique string into the lock files. Renovate logged “Post-upgrade file saved” (it read the new content), but git show on the committed branch showed the old content with no marker.

Suggested fix

Option A (minimal & safe – recommended)
Change .find() → .filter() in execute-post-upgrade-commands.ts and update all matching entries:

const matchingArtifacts = updatedArtifacts.filter(
  (ua) => ua.path === relativePath && ua.type === 'addition'
);
for (const art of matchingArtifacts) {
  art.contents = existingContent;
}

Option B – Deduplicate updatedArtifacts earlier (before committing).
Option C – Prevent duplicate appends at the updateArtifacts() layer (cleanest long-term).

We verified Option A with a patch on our self-hosted Docker instance — all post-upgrade changes now land correctly in the committed branch.

Links

• Original Issue (auto-closed): postUpgradeTasks: .find() in execute-post-upgrade-commands only updates first duplicate updatedArtifact — stale content committed #42710
• Renovate version: 43.111.1
• Platform: Azure DevOps (self-hosted Docker)

Disclosure

This bug was discovered through the use of Agentic AI (GitHub Copilot + Claude) with a developer guiding the investigation on a real production .NET monorepo.

Logs (if relevant)

Logs

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

[ImperiumTakp]

i would love some feedback, if we need to provide a target repo as a means to make it reproducable then we should be able to somehow create that, though it might not be as straight forward since it is based on an inner source project with many Nuget Packages with internal among them.

[jamietanna]

Yes, a reproduction would be appreciated

[github-actions[bot]]

Hi there,

Please help this Discussion progress by creating a minimal reproduction. This means a repository dedicated to reproducing this issue with the minimal dependencies and config possible.

Before we start working on your issue we need to know exactly what's causing the current behavior. A minimal reproduction helps us with this. Discussions without reproductions are less likely to be converted to Issues.

Please follow these steps:

1. Read our guide on creating a minimal reproduction.
2. Go to our minimal reproduction template repository.
3. Select the Use this template button to create a new repository based on the template.
4. Work on the reproduction in your own repository. Ensure it's actually minimal (no unnecesary dependencies or config), or it will be rejected by maintainers.
5. Install the Renovate app to verify that what you say happens (or doesn't happen) reproduces.
6. Fill out the information in your repository's README.md. What you describe there should reflect what you see in this repo, with the hosted app, and not what you saw in your original repo/environment.
7. Add the link to your reproduction to the first post of your Discussion. If you are not the original author, you can post a new comment with the link.
8. Add a Discussion comment mentioning that the reproduction repo is now available and linked.

If you need help with running Renovate on your minimal reproduction repository, please refer to our Running Renovate guide.
Good luck,

The Renovate team

[dlm6693]

We hit this independently on a Go workspace monorepo, so here is a minimal reproduction and a fix.

Reproduction: https://github.com/dlm6693/renovate-repro-42729

Two modules in a go.work workspace, postUpdateOptions: ["gomodTidyAll"], and a postUpgradeTasks script that appends a marker line to both go.sum files. It is shaped so one path gets a duplicate updatedArtifacts entry and the other gets a single entry, so the difference shows up in one branch: lib/go.sum keeps the marker, app/go.sum loses it.

Fix: #45891 — Option A from the original report, plus a unit test that fails on main with the second entry still holding the stale content.

How the duplicates arise for gomod, in case it is useful alongside the .NET case: gomodTidyAll makes a shared module's updateArtifacts() call return its dependents' go.mod/go.sum through dependentFiles, while each directly-updated module's own call already returned its own files. Any path in both sets ends up with two entries.

Production evidence. On a grouped non-major bump across a 10-module workspace, Renovate logged Updated 35 lock files covering 21 unique paths, ran make tidy, and logged Post-upgrade file saved 22 times. Exactly 14 paths had two entries, and exactly those 14 files were committed with pre-make tidy content. The 7 single-entry paths were committed correctly. The one-to-one match between "has a duplicate entry" and "committed stale" is what pointed at the .find() rather than at the tidy step.

[dlm6693]

Both branches Renovate pushed during that verification are preserved in the reproduction repo, so the result can be checked without re-running anything:

• evidence/unpatched-main — run on main (282a0f3)
• evidence/with-fix — same run with this PR applied

The only difference between them is the single line the bug dropped:

$ git diff origin/evidence/unpatched-main origin/evidence/with-fix
--- a/app/go.sum
+++ b/app/go.sum
@@ -1,2 +1,3 @@
+// renovate-post-upgrade-marker

Use a two-dot diff; GitHub's compare view is three-dot and also shows the dependency bump against main.

lib/go.sum has the marker on both branches. It is the same postUpgradeTasks script writing to both files in the same run — the only thing that differs is that app/go.sum had two updatedArtifacts entries and lib/go.sum had one.

[namabile]

Adding a third ecosystem: uv workspaces (pep621 manager). We reproduced it end to end with self-hosted 44.104.0. The code cited below is unchanged in 44.126.0 and on main, and so are the line numbers, apart from the one get-updated.ts shift noted.

When uv produces duplicate entries

Every member of a uv workspace shares the one uv.lock at the workspace root. Within a branch, Renovate calls updateArtifacts() once for each member pyproject.toml that has an update. Each call does three things:

1. It reads the lock from disk (lib/modules/manager/pep621/processors/uv.ts:206).
2. It runs uv lock --upgrade-package … from that member.
3. It returns the lock only if that relock changed it (:248 → updateLockFile() in lib/modules/manager/util.ts:175-209, which otherwise logs uv.lock is unchanged at :204).

processUpdateArtifactResults() then appends each returned file (lib/workers/repository/update/branch/get-updated.ts:638 in 44.104.0, :639 in 44.126.0).

So a second uv.lock entry appears only when a later member's relock changes the lock again:

• Two members relocking the same upgrade did not trigger it in our run (a and b both pinning six, the fourth control row below). The second relock logged uv.lock is unchanged, and the branch got a single entry.
• One grouped branch in which each member relocks a different package does trigger it. In the reproduction below, two members produce two entries, the second a later state of the lock than the first.

From there it is the path already described above:

• execute-post-upgrade-commands.ts:87-101 writes every entry to disk before the task runs, in array order, so the file on disk holds the last entry.
• After the task runs, :313-317 refreshes only the entry that .find() returns, which is the first one.
• prepareCommit() (lib/util/git/index.ts, the for (const file of files) loop at :1411) writes the entries in order. The last entry, still holding its relock without the task's change, wins.

Minimal reproduction

This needs self-hosted Renovate, because the task must match allowedCommands, a global-only option. Commands are blocked by default on Mend-hosted apps.

.
├── renovate.json
├── post-upgrade.sh
├── pyproject.toml
├── a/pyproject.toml
├── b/pyproject.toml
└── uv.lock

pyproject.toml (workspace root):

[project]
name = "root"
version = "0"
requires-python = ">=3.12"

[tool.uv.workspace]
members = ["a", "b"]

a/pyproject.toml:

[project]
name = "a"
version = "0"
requires-python = ">=3.12"
dependencies = ["six>=1.15"]

b/pyproject.toml:

[project]
name = "b"
version = "0"
requires-python = ">=3.12"
dependencies = ["idna>=3.0"]

uv.lock: generated with uv lock against PyPI while a pinned six==1.16.0 and b pinned idna==3.6, then relocked once the pins were relaxed to the ranges above. It therefore locks six 1.16.0 and idna 3.6.

post-upgrade.sh:

#!/bin/sh
printf '# post-upgrade-marker\n' >> uv.lock

renovate.json:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "enabledManagers": ["pep621"],
  "rangeStrategy": "update-lockfile",
  "groupName": "all dependencies",
  "postUpgradeTasks": {
    "commands": ["sh post-upgrade.sh"],
    "fileFilters": ["uv.lock"],
    "executionMode": "branch"
  }
}

We ran it with "allowedCommands": ["^sh post-upgrade\\.sh$"] and binarySource=global (uv 0.12.11 on PATH), using platform=gitea against a local Gitea 1.27.2.

Expected: branch renovate/all-dependencies commits a uv.lock ending in # post-upgrade-marker.

Actual (44.104.0):

• From a: uv lock --upgrade-package six (six 1.16.0 → 1.17.0).
• From b: uv lock --upgrade-package idna (idna 3.6 → the latest release, 3.20 when we ran it).
• The log shows Updated 2 lock files with "updatedArtifacts": ["uv.lock", "uv.lock"], then Post-upgrade file saved for uv.lock.
• The committed uv.lock is the second relock (six 1.17.0, latest idna) without the marker.

Controls (same binary and setup):

Variant	updatedArtifacts	Marker committed
The reproduction above	["uv.lock", "uv.lock"]	no
b removed from the workspace and from members	["uv.lock"]	yes
Both ranges declared in a (one uv lock --upgrade-package idna --upgrade-package six)	["uv.lock"]	yes
a and b both pin six==1.16.0, no rangeStrategy or groupName (the second relock logs uv.lock is unchanged)	["uv.lock"]	yes
#45891's change applied to the 44.104.0 dist	["uv.lock", "uv.lock"]	yes

With #45891 applied, the committed uv.lock differs from the unpatched commit only by the marker line.

A task that fails after writing. Same tree, but post-upgrade.sh appends the marker and then runs exit 1:

• Unpatched:
  • Renovate records artifactErrors: [{"stderr": "Command failed: sh post-upgrade.sh\n"}].
  • It still creates the branch (branchExists=false, then Branch created). With artifact errors, the branch worker proceeds once the release is more than two hours old, so the log line PR is older than 2 hours, raise PR with lock file errors is about releaseTimestamp, not an existing PR (lib/workers/repository/update/branch/index.ts:708-715 in 44.104.0).
  • The committed uv.lock is identical to the unpatched commit from the passing task, so the marker is dropped there too.
• With fix(post-upgrade-commands): update all duplicate updatedArtifacts entries #45891 applied: the same artifact error is recorded, and the marker is committed.

Fix

#45891 fixes both cases on this tree.

Collapsing the duplicate addition entries for a path to one entry before the .find() also works. We run that as a local patch on 44.104.0, and on this tree it commits the same uv.lock as #45891, for both the passing and the failing task.