Don't continue on dependency fetch errors

[glensc]

Tell us more.

My self hosted renovate run sometimes (quite often) gets timeouts:

DEBUG: GET https://repo.packagist.org/p2/intervention/image.json = (code=ETIMEDOUT, statusCode=-1 retryCount=2, duration=7620)
DEBUG: Datasource connection error
       "datasource": "packagist",
       "packageName": "intervention/image",
       "errCode": "ETIMEDOUT"
DEBUG: Failed to look up packagist package intervention/image (packageFile=composer.json)

And this results merge request being closed as renovate thinks there's no update involved.

And next time it r uns again, it creates the merge requests.

This creates annoying flapping merge requests that have been re-created. It loses history of existing merge requests, for example ~renovate-stop-updating labels. it shouldn't even touch the existing ones.

[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

[glensc]

Summary

Self-hosted Renovate runs sometimes time out when fetching Packagist metadata (ETIMEDOUT). When that happens Renovate treats the dependency as unresolved and closes the MR / considers there's no update, then on a subsequent run it recreates the MR. This leads to flapping merge requests and lost MR state (labels, discussion history, etc.).

Original report / context: #43643

Screenshot:

Reproduction goal

Create a minimal, reliably repeatable repro that demonstrates Renovate closing an existing dependency MR (or not updating it) after a datasource fetch timeout, and then recreating it on a later run.

Environment

• Renovate: self-hosted (container)
• Datasource: packagist (Composer)
• Example package: intervention/image
• Example repo: minimal composer.json shown below

Minimal repository

Create a repository with the following composer.json at the repository root:

{
  "name": "example/repro",
  "require": {
    "intervention/image": "^2.5"
  }
}

Steps to reproduce (network-failure simulation)

1. Start Renovate self-hosted pointing at the minimal repository above. Use whatever config you normally use; minimal renovate.json example:

{
  "extends": ["config:base"],
  "enabledManagers": ["composer"],
  "automerge": false
}

2. Run Renovate once with normal network access so it creates an MR for the dependency update (if one is available). Confirm MR exists and has labels/discussion.

3. Simulate a Packagist timeout for the next run. Two ways to do this depending on environment:

Option A — Using tc/netem (Linux):

• Identify the host's interface (e.g., eth0). Then, temporarily drop packets to repo.packagist.org for a single Renovate run:

sudo tc qdisc add dev eth0 root netem loss 100% dst 151.101.0.0/16
# Run Renovate once (the run that should hit packagist and time out)
# Then remove rule:
sudo tc qdisc del dev eth0 root netem

Option B — Using iptables to drop traffic to repo.packagist.org:

# Resolve packagist IPs (may be multiple)
for ip in $(dig +short repo.packagist.org); do sudo iptables -A OUTPUT -d $ip -j DROP; done
# Run Renovate
# Then remove rules:
for ip in $(dig +short repo.packagist.org); do sudo iptables -D OUTPUT -d $ip -j DROP; done

Option C — Run Renovate with an HTTP proxy that simulates a timeout or closes connections for https://repo.packagist.org/p2/* while allowing other traffic.

4. Confirm Renovate logs show ETIMEDOUT / datasource connection error similar to the report:

DEBUG: GET https://repo.packagist.org/p2/intervention/image.json = (code=ETIMEDOUT, statusCode=-1 retryCount=2, duration=7620)
DEBUG: Datasource connection error
  "datasource": "packagist",
  "packageName": "intervention/image",
  "errCode": "ETIMEDOUT"
DEBUG: Failed to look up packagist package intervention/image (packageFile=composer.json)

5. Observe behavior: Renovate should (per report) close the existing MR or treat the dependency as not updated. Note exact actions (closed MR, removed labels, recreated MR on next run, etc.).

6. Restore normal network access and run Renovate again. Confirm it creates a new MR for the same dependency and that the previous MR's history/labels were not preserved (i.e., flapping).

What to assert / test checks

• On the run where Packagist fetch times out, Renovate logs an ETIMEDOUT and the run does not modify non-related MRs.
• Renovate does not delete or close the existing dependency MR when facing datasource timeouts (expected). If it does, capture the exact state transitions and timestamps.
• After restoring network access, Renovate creates a new MR for the same dependency rather than reusing the original.

Notes / hypotheses

• The bug report indicates Renovate may treat a datasource fetch failure as "no update" and either close/stale the existing MR or remove its tracking state, causing recreation on the next successful fetch. The reproducer should confirm whether MR metadata (labels like "~renovate-stop-updating") are lost.

• If the above repro is not reliably reproducing, try increasing the frequency of runs or add additional dependencies to increase the chance of hitting timeouts.

Optional: Node-level mocking for faster CI repro

If you want a CI-friendly reproducible test that doesn't require manipulating host networking, create a small integration test that stubs the Packagist datasource call to throw a timeout error for a single run. Example approach:

• In Renovate's tests, mock the datasource module that fetches packagist metadata (the module that makes the GET request to repo.packagist.org) to throw an ETIMEDOUT error on the first call for intervention/image and succeed on subsequent calls.
• Run the renovate process twice within the test harness and assert the MR lifecycle behavior (first run causes MR to be closed or treated as no-update; second run creates new MR).

Logs / references

• Original discussion: Don't continue on dependency fetch errors #43643

[RahulGautamSingh]

I have started a discussion internally in the maintainer's group. Will update once there's some direction on way forward.

[esetnik]

[Written by Claude]

Adding a corroborating data point from the Mend.io-hosted app (so this isn't limited to self-hosted): same signature, renovateVersion 43.219.0, runner host jr-microvm, datasource packagist.

GET https://repo.packagist.org/p2/illuminate/collections.json = (code=ETIMEDOUT, statusCode=-1 retryCount=2, duration=408)
Datasource connection error  "datasource":"packagist"  "errCode":"ETIMEDOUT"
Failed to look up packagist package illuminate/collections: no-result

The part that may help triage: the failure is cache-gated, which explains the "sometimes (quite often)" intermittency. I compared two consecutive runs of the same pipeline (full extract + lockFileMaintenance), 21 minutes apart:

	Run A (cold cache)	Run B (+21 min, warm cache)
live repo.packagist.org requests	3	0
ETIMEDOUT connection errors	3	0
Failed to look up … no-result	yes (2 packages)	none
total completed outbound GETs (any host)	3	0 (everything cache-served)

A dependency only fails when its datasource-cache entry is cold (forcing a live request) and the packagist connection happens to time out at that instant. A failed lookup isn't cached as a durable success, so it re-attempts on the next cold run — effectively a coin-flip on the network. When the cache is warm (Run B), the dep never touches the network and always resolves, regardless of egress health. That's the mechanism behind the flapping PRs described here: a transient ETIMEDOUT is silently converted to no-result ("no versions / no update") instead of being treated as a host/connection error.

One note on the connection itself: my ETIMEDOUT fails fast (~400ms), versus ~7.6s in the original report. A sub-second ETIMEDOUT to a Fastly-backed host looks consistent with the IPv6-first / no-IPv4-fallback behavior discussed in #21009 — worth keeping in mind for hosted-runner egress.

Net ask (same as OP): a transient per-dependency connection error (ETIMEDOUT / statusCode=-1) shouldn't be classified as no-result, and shouldn't close/recreate existing PRs — ideally it should be treated as a host/connection error (à la abortOnError / external-host-error) so existing PRs and their state (labels, history) are preserved.