Renovate exits with code 0 in the middle of the process

[florianmutter]

What would you like help with?

I think I found a bug

How are you running Renovate?

Self-hosted

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

In most of the runs renovate just stops when processing the last dependency (at least I think this is where it is). It exits with status code 0. Here is the end of the log of a "failed" run:

In a successful run it continues to list all the packages it finds:

Logs (if relevant)

Logs are to long for inline. File attached:
job-logs.txt

[rarkins]

It's unlikely that renovate is exiting itself without any message. Most likely is that the process or container is being killed by the OS or scheduler, such as for out of memory problems.

[florianmutter]

Finally found some time to dig into this. It looks like node exits right at this line in fetch.ts:

await Promise.all(allManagerJobs);

The very next line is a log message that we do not see. This feels like there is a promise that does not resolve (see nodejs/node#29355 or nodejs/node#43162).

[maxbrunet]

I have been trying to debug the same issue for hours, I checked everything I could think of, there is no resource pressure, Renovate exits with code 0, and when it happens there is always at least 1 manager that does not reach this line:

renovate/lib/workers/repository/process/fetch.ts

Line 153 in e78fb57

logger.trace({ manager }, 'fetchManagerUpdates finished');

Or a package file does not reach this line to be little more granular:

renovate/lib/workers/repository/process/fetch.ts

Line 135 in e78fb57

logger.trace({ packageFile }, 'fetchManagerPackagerFileUpdates finished');

It is not consistent, but the bigger the repo, the more likely it is to occur. No way to tell why the Node process exits

[jSherz]

We're experiencing the same issue on a large monorepo. I've tried running with NODE_OPTIONS="--max-old-space-size=16384 --trace-exit --trace-sigint --trace-uncaught --unhandled-rejections=warn --trace-warnings" and debug logs and don't see anything to indicate what's happening.

As above, we don't have resource pressure and Renovate just exits with code 0.

I'm very happy to try things on our setup if you have any leads?

[tudor21211]

Hi, did you find any solution to this? it is still reproducing and i cannot figure out why, here is the last log i see before it exits without throwing any error message

TRACE: fetchManagerPackagerFileUpdates finished (packageFile=pom.xml)
TRACE: fetchManagerUpdates finished
            "manager": "maven"

[maxbrunet]

I have limited time to troubleshoot this, but what I would recommend to other users affected is trying to narrow down the issue to a manager, and then a package file, and then a package hopefully, by applying the following method, a sort of dichotomic search:

Phase 1: Manager

1. Get the list of managers used in the repo (there is a log early in the run that lists them called manager extract durations (ms))

2. Disable half of the managers in the repo's renovate.json

   {
     "<manager1>": { "enabled": false },
     "<manager1>": { "enabled": false },
     // ...
     "<managerN>": { "enabled": false }
   }

3. Let Renovate run for some time. If that solves the issues, re-enable half of the managers you disabled at the previous step. If it does not, re-enable them all, and disable the other half.

4. Repeat from step 2 until you have only one manager left disabled without issues (it could be possible there are more than one manager, but I really hope not 😄)

Phase 2: Package file

1. Get the list of package files matched by the manager(s)

2. Disable half of the package files with package rules:

   {
     "packageRules": [
       {
         "matchManagers": ["managerX"],
         "matchFileNames": [
           "path/to/packageFile1",
           "path/to/packageFile2",
           // ...
           "path/to/packageFileN",
         ],
         "enabled": false 
       }
     ]
   }

3. Let Renovate run for some time. If that solves the issues, re-enable half of the package files you disabled at the previous step. If it does not, re-enable them all, and disable the other half.

4. Repeat from step 2 until you have the minimum of package files disabled without issues

Phase 3: Package

1. Get the list of packages in the package files

2. Disable half of the packages with package rules:

   {
     "packageRules": [
       {
         "matchManagers": ["managerX"],
         "matchFileNames": ["path/to/packageFileX"],
         "matchDepNames": [
           "dep1",
           "dep2",
           // ...
           "depN"
         ],
         "enabled": false 
       }
     ]
   }

3. Let Renovate run for some time. If that solves the issues, re-enable half of the packages you disabled at the previous step. If it does not, re-enable them all, and disable the other half.

4. Repeat from step 2 until you have the minimum of packages disabled without issues

Phase 4: Report

Report the manager and possibly package(s) affected. Try to create and share a minimal reproduction with these details.

Even if you are not able to go through it all, please report your findings somebody else might be able to pick up debugging where you left off, having some reports from phase 1 would be a great start

[Xenon341]

Same problem here on some project.

Debug view show something like

DEBUG: Found 24 new releases for org.pitest:pitest-junit5-plugin in repository https://mynexus/repository/maven-public/ (repository=MyGitProject) DEBUG: http cache: saving https://mynexus/repository/maven-public/org/pitest/pitest-junit5-plugin/1.2.3/pitest-junit5-plugin-1.2.3.pom (etag="fb54e1ad20337a9e3ae9ff8648379b98", lastModified=Tue, 20 May 2025 15:48:19 GMT) (repository=MyGitProject)

And then stops without any error.

[tudor21211]

Hello, the fix for me was to limit the enabledManagers to maven only. You can achieve this using "enabledManagers":["maven"]. The issue comes from the error when trying to pull dependencies for other managers you don't have access to.

[Xenon341]

Unfortunately, I have project with only maven manager that have the problem.
For one of them, it's one maven dependency that cause the problem : org.ow2.asm so I needed to disable for this package

[Xenon341]

Ok some leads for my case at least for a maven project.
Seems like there is a problem getting the chagelog on some URL.
We are in a corporate install and not every internet URL are authorized.

The two hosts that seems to cause issue : api.bitbucket.org and https://gitbox.apache.org
We understand that Renovate use the scm information from the maven pom file of the dependency to try to get the changelog.
With the host match rule we disabled those URL so the changelog are not fetched and it seems to work.
So, maybe some HTTP return code or Proxy response that the bot doesn't like maybe ?

As a side note, when a URL was not whitelisted in our proxy, we had a 407 or 403 http return code.
Now curl is showing a connection abort so maybe the bot is not happy with that in my case.

[maxbrunet]

For us, one problem seems to be with the public.ecr.aws container registry, especially public.ecr.aws/docker/library/golang, but not clear if it is really this repository or we are crossing some sort of threshold when enabling it (we use multiple repositories with a variety of tags: node, python, postgres... alpine, debian... variants). A speculation: it could happen when the "Rate of unauthenticated image pulls" of "1 per second" is crossed by the concurrent promises for example

https://docs.aws.amazon.com/AmazonECR/latest/public/public-service-quotas.html

I am still going through re-enabling managers for our largest monorepo (slowly), so I might find other cases

[maxbrunet]

Tested with docker.io/library/golang and the same issue occurs, so it seems to happen with the repository rather a specific registry. I have many Git repositories referencing this image without issues, although these repositories never reference it more than once, could that be a problem with multiple references? Tags/Flavors (Alpine or Debian) also vary 😕

[Chumper]

Not sure if that helps, but we had the same issue in the past and it was caused by versions checks to docker.io, which failed with 429 errors. That causes the whole process to abort.
We then used abortOnError to not abort when there is an error on docker.io: https://docs.renovatebot.com/configuration-options/#abortonerror
It is false by default, but maybe you are setting it somewhere in the config?

So I would check if any registry returns any 4XX error.

[maxbrunet]

I have had 429 errors in the past, but it is a silent exit in this case, these is no 429, no log regarding aborting. iirc aborts logs and stops processing the current repository, but moves on to process the other repositories, here Renovate exits silently without error in the middle of fetching package updates

[jSherz]

I've managed to replicate this issue successfully with large dependencies, for example the Python package aiohttp which has a decompressed body of 7MB, and the NPM package typescript. Attached is a packet capture and TLS keys showing an example failed request. I instrumented the Renovate bot code as follows:

lib/util/http/got.ts:

export async function fetch(
  url: string,
  options: SetRequired<GotOptions, 'method'>,
  queueStats: QueueStatsData,
): Promise<HttpResponse<unknown>> {
  logger.trace({ url, options }, 'got request');

  let duration = 0;
  let statusCode = 0;
  try {
    // Cheat the TS compiler using `as` to pick a specific overload.
    // Otherwise it doesn't typecheck.
    gotsStarted++;
    waitingFor[url] = true;
    const resp = await got(url, { ...options, hooks } as GotBufferOptions);
    delete waitingFor[url];
    gotsFinished++;
    statusCode = resp.statusCode;
    duration = coerceNumber(resp.timings.phases.total, 0);
    return resp;
  } catch (error) {
    delete waitingFor[url];
    gotsRejected++;

On a failed run, gotsStarted - gotsFinished - gotsRejected > 0, i.e. the promise was started but never resolved or rejected.

short.zip

[jSherz]

The Renovate bot has now been migrated to ESM and got has been upgraded. Any improvements? @florianmutter @maxbrunet @tudor21211 @Chumper ?

It's too early for us to fully trust it's resolved, but we haven't seen it get stuck since.