Changelog parsing re-parses a large CHANGELOG.md for every version (38 of 59 minutes on aws-sdk-rust)

[AllyMarthaJ]

How are you running Renovate?

Self-hosted

Which platform you running Renovate on?

github.com

Which version of Renovate are you using?

44.176.2

Please tell us more about your question or problem

getReleaseNotesMd re-parses the whole changelog for every version in an upgrade. It calls sectionize at each heading level (1 to 7), calling markdown.parse and splitting the file into lines each time. That means seven parses of the same text per version, repeated for every upgrade in the branch, even though the result is unchanged.

We barely notice this with most changelogs, but spend most of our run parsing a large monorepo changelog. awslabs/aws-sdk-rust has a 10.8 MB CHANGELOG.md. Parsing it seven times takes about 1.4 s per version on an M-series laptop, and longer on our Graviton agent. For an aws-sdk-ec2 security PR covering three upgrades and about 184 intermediate versions, we spent 658 s parsing it. Across eight aws-sdk crate branches, we spent 38 of 59 minutes here, with no output at debug level.

We get no release notes for that time: the headings are dates (October 22nd, 2026) and the GitHub releases are named release-YYYY-MM-DD, so no version matches. We never reach the platform-limit cut-off from #45503 either, because no notes accumulate.

With one parse per repository run, we can reuse the heading positions for every level and version. In a local benchmark against that changelog, I measured 35 ms per version, down from 1384 ms, after a single 190 ms parse. I have a change ready and will open a PR referencing this discussion.

You can reproduce this with any repository that depends on an outdated aws-sdk-* crate. The cost is in parsing the upstream changelog, regardless of the repository being renovated.

I wrote this analysis and the change with an AI agent (Claude Code, Claude Fable 5.1). The measurements are from our own runs.

Logs (if relevant)

Debug logs from one branch, with Buildkite timestamps. Between Fetching changelog and creating the PR, we are parsing the changelog as described above:

06:58:42 DEBUG Fetching changelog: https://github.com/awslabs/aws-sdk-rust (1.253.0 -> 1.254.0)
07:09:40 DEBUG Creating PR prTitle=Update Rust crate aws-sdk-ec2 [SECURITY]

[AllyMarthaJ]

I found a second problem in the same runs. I think it's worth discussing here rather than in #47334.

We saw no benefit from a warm package cache for this repository. We restored the previous run's cache on the next run and spent the same time on the same eight branches: 703 s on aws-sdk-ec2 against 691 s cold, 473 s on aws-sdk-lambda against 478 s.

I traced this to addReleaseNotes. For each version, Renovate reads the cached notes. On a miss, it fetches them and writes the result back with packageCache.set. If there are no notes and no compare URL, it writes null. That's the case for aws-sdk-rust because its tags are release-YYYY-MM-DD rather than crate versions. On the next run, Renovate gets null from packageCache.get and treats it as a miss at if (!releaseNotes), then repeats the full lookup. So we never cache the "no notes" outcome and repeat the parse for every version on every run.

We could fix this by storing a sentinel for "looked, found nothing" and treating it as a hit until its TTL expires. With the existing TTL logic from releaseNotesCacheMinutes, we already use a short TTL for recent versions, so we'd still pick up a late-published changelog. I'm happy to send a separate PR once you've looked at #47334, if you agree it's worth doing.

Written with the same AI agent as the report above (Claude Code, Claude Fable 5.1); the timings are from our runs.