Wrong changelog content when updating different dependencies that come from the same repository

[stekern]

How are you running Renovate?

A Mend.io-hosted app

If you're self-hosting Renovate, tell us which platform (GitHub, GitLab, etc) and which version of Renovate.

GitHub

Please tell us more about your question or problem

Problem

I have a monorepo (a library of sorts) containing releases for many different dependencies. Releases point to tags that follow the naming convention <dependency-name>-v<version> (e.g., example-v1.0.0, another-v1.0.0, etc.) to separate them.

In consuming repositories I am using a custom Regex manager to keep these dependencies updated. For the most part this works quite nicely, but I've noticed that sometimes the changelog content in the PRs created by Renovate for these dependencies include entries from other dependencies in the monorepo. As an example, the changelog for upgrading dependency example from v1.0.0 to v1.0.1 includes a changelog entry v1.0.1 that actually belongs to the another dependency.

Reproduction

This was tricky to troubleshoot as I couldn't find anything useful in the (debug) logs, but I've finally managed to create a minimal reproduction. It seems to come down to cache key collisions, and these are the conditions that seem to trigger it:

1. Multiple dependencies pointing to same source repository (e.g., through packageName)
2. Renovate processes PRs for multiple dependencies that have releases in the same source repository
3. The dependencies have overlapping versions in their changelog ranges

These conditions will lead to the dependency being processed first (e.g., another) "poisoning" the cache that is later used by another dependency (e.g., example).

See the following for a minimal reproduction repository that functions both as an example monorepo containing multiple dependencies, and as a consumer of the same dependencies: https://github.com/stekern/renovate-repro-monorepo-changelog-issue.

Notice that the PR for updating the example dependency contains the wrong changelog content stekern/renovate-repro-monorepo-changelog-issue#2.

I've reproduced this both in the hosted and self-hosted version (through GitHub Actions).

Potential root cause

There might be other mechanisms behind the behavior, but I've found at least two methods that seem to explain some of it. The following cache keys set by Renovate are not unique per dependency in a monorepo, causing collisions when versions overlap for different dependencies in the same repository:

1. addReleaseNotes(): ${repository}:${version} (or ${repository}:${sourceDirectory}:${version} if sourceDirectory is set)
2. getChangeLogJSON(): ${sourceUrl}:${packageName}:${prev}:${next}

Mitigations

I've discovered two imperfect workarounds that involve using the sourceDirectory configuration option to:

1. Point to a unique directory per dependency that contains a CHANGELOG.md, which takes precedence over release notes (e.g., "sourceDirectory": "{{depName}}")
2. Point to a non-existing directory in order to get unique cache keys across dependencies in the same source repository (e.g., "sourceDirectory": "cache-key-{{depName}}"). Since this directory does not exist in the source repository, it seems to fall back to using release notes which are then cached under a unique key.

Both of these workarounds give me PRs with correct changelog entries, but the Compare Source links are still wrong - presumably because they come from the cache layer in getChangeLogJSON(). I tried to come up with a similar workaround for fixing the links, but the only somewhat feasible way I could think of without breaking anything else seemed to be modifying the sourceUrl by adding a unique number of trailing slashes (which are later stripped out) per dependency to get a unique cache key. But that feels very, very wrong.

Is the behavior I've described here expected? If so, is this something you would consider implementing support for? I haven't had other issues with monorepos in Renovate, so it's already very functional. It's also a somewhat common way to organize dependencies. Naively I think having depName as part of all relevant caching layers would solve the issue, but that might have other side effects. Alternatively the ability to turn off caching (e.g., for specific operations, repositories and/or dependencies) might also be a solution, but that might not be an ideal way to go.

Logs (if relevant)

Logs

DEBUG: Found existing PR (branch="renovate/another-1.x")
DEBUG: Fetching changelog: https://github.com/stekern/renovate-repro-monorepo-changelog-issue (1.0.0 -> 1.0.1) (branch="renovate/another-1.x")
DEBUG: http cache: saving https://api.github.com/repos/stekern/renovate-repro-monorepo-changelog-issue (etag=W/"83f2448120247d34923d57354128b6574db699e17d6f837d7118714dffe1d3a7", lastModified=Thu, 10 Jul 2025 07:29:50 GMT) (branch="renovate/another-1.x")
DEBUG: http cache: saving https://api.github.com/repos/stekern/renovate-repro-monorepo-changelog-issue/git/trees/main (etag=W/"e18eddc055fba2190dc49e6b89e364100df228a994b6ff8111208ef27f104731", lastModified=Thu, 10 Jul 2025 07:29:50 GMT) (branch="renovate/another-1.x")
DEBUG: Processing existing PR (branch="renovate/another-1.x")

...

DEBUG: Found PR #2 (branch="renovate/example-1.x")
DEBUG: Found existing PR (branch="renovate/example-1.x")
DEBUG: Fetching changelog: https://github.com/stekern/renovate-repro-monorepo-changelog-issue (1.0.0 -> 1.0.1) (branch="renovate/example-1.x")
DEBUG: Processing existing PR (branch="renovate/example-1.x")

[rarkins]

@zharinov could you take a look at the caching issue?

[rarkins]

@stekern thanks for the good analysis to narrow it down to caching. @zharinov has worked in this area before so I've asked him to add it to his todo list