PR body with ~130 embedded release notes exhausts the heap regardless of --max-old-space-size

[smoochy]

How are you running Renovate?

Self-hosted Renovate CLI

Which platform you running Renovate on?

GitHub.com

Which version of Renovate are you using?

44.46.0 (self-hosted via npx renovate@44)

Please tell us more about your question or problem

A single Docker image pinned more than one major behind produces an update whose changelog spans roughly 130 releases. Renovate fetches all of them and embeds them in one pull request body, and compiling that body exhausts node's heap:

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

Raising the heap does not reach it. I measured three ceilings; each was honoured by V8, and each run died at the same point after roughly 300 seconds:

--max-old-space-size	last GC record before the fatal error	result
default (~4 GB)	4068.9 (4102.1) MB	OOM at 322s
8192	8094.5 (8153.1) MB	OOM
16384	16526.3 (16655.9) MB	OOM at 297s

Where it fails: in body rendering, not in fetching. The changelog fetch completes: the trace log shows the containous/traefik API responses cached and 276 Found release notes for ... records written. On a trace-level run the last 200 MB of the ndjson log contain exactly three records, two of them Compiling template, and one single log line is over 50 MB - roughly the size of the object being compiled.

Release notes gathered for that one update, by major:

6 x 2.10   53 x 2.11   5 x 3.0   8 x 3.1   6 x 3.2
8 x 3.3     5 x 3.4    6 x 3.5  24 x 3.6  11 x 3.7   = 132

Minimal reproduction: a scratch repository whose only relevant content is

services:
  traefik:
    image: traefik:v2.10.0@sha256:b345035951713456bb269c75952d4ec79358484b7c03165d41957d8aaf0f9357

with a config extending config:recommended. separateMajorMinor is on by default, so this yields a v3 major update whose changelog spans the whole v2.10 -> v3.7 range. Any image pinned comparably far behind should behave the same.

Workaround I am using: fetchChangeLogs: "off" scoped to that one package makes the same run complete normally. It works, but it means the update gets no body content at all rather than a truncated one.

The question: is an unbounded number of embedded release notes intended? I would have expected either a cap on how many are embedded, or a fallback to a summary plus a compare link once the collected notes exceed some size - rather than the run failing with an unrecoverable V8 error at whatever ceiling it is given. If a bound is wanted, I am happy to turn this into an issue with whatever extra detail you need.

Logs (if relevant)

Logs

"msg":"Fetching changelog: https://github.com/containous/traefik (v2.10.0 -> v3.7.11)"
"msg":"http cache: saving https://api.github.com/repos/containous/traefik ..."
"msg":"http cache: saving https://api.github.com/repos/containous/traefik/git/trees/master ..."
"msg":"http cache: saving https://api.github.com/repos/containous/traefik/git/blobs/6027cf5a... ..."
...
"msg":"Compiling template"

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

The full trace log is 2.2 GB but I can extract any slice.

[github-actions[bot]]

Hi there,
We notice that the Discussion you've created doesn't quite follow our template.
Please update the top-level comment in this Discussion to follow the structure of the template.
This improves the maintainers' time to triage, as key information is clearly indicated in the format we expect.
Thanks, the Renovate team

[jamietanna]

There's a couple of Issues I need to raise around this - will try and get them raised today