Regex manager mutates depName when updating currentValue without autoReplaceStringTemplate

[Boemeltrein]

How are you running Renovate?

Self-hosted Renovate CLI

Which platform you running Renovate on?

Other (please specify)
Kubernetes, container ghcr.io/mend/renovate-ce

Which version of Renovate are you using?

"renovateVersion": "43.259.2"

Please tell us more about your question or problem

I figured this out together with ChatGPT and enabled LOG_LEVEL=debug
As I not that great in a nice english summary hereby the AI generated version.
Sorry about that.

---

Regex manager mutates depName when updating currentValue without autoReplaceStringTemplate
Description

I believe I've found an issue with the regex custom manager when using a numeric depName and no autoReplaceStringTemplate.

The dependency is extracted correctly, but during a subsequent branch update Renovate reports a depName mismatch because the depName has been unexpectedly modified. Adding an explicit autoReplaceStringTemplate resolves the issue.

Renovate configuration

customDatasources: {
    "grafana-dashboards": {
      defaultRegistryUrlTemplate: "https://grafana.com/api/dashboards/{{packageName}}",
      format: "json",
      transformTemplates: [
        '{"releases":[{"version": $string(revision)}], "sourceDirectory": name}',
      ],
    },
  },
customManagers: [
    {
      description: "Process Grafana dashboards (grafanaCom)",
      customType: "regex",
      managerFilePatterns: ["/grafanadashboard\\.yaml(?:\\.j2)?$/"],
      matchStrings: [
        "grafanaCom:\\s*\\n\\s*id:\\s*(?<depName>\\d+)\\s*\\n\\s*revision:\\s*(?<currentValue>\\d+)",
      ],
      datasourceTemplate: "custom.grafana-dashboards",
      versioningTemplate: "regex:^(?<major>\\d+)$",
    },
  ],

Example input

grafanaCom:
  id: 13768
  revision: 7

The regex extracts:

depName = 13768
currentValue = 7

The Grafana datasource returns revision 8.

Expected behavior

The dependency should update to:

grafanaCom:
  id: 13768
  revision: 8

The depName should remain 13768.

Actual behavior

On a subsequent run, Renovate fails while updating the existing branch with:

DEBUG: depName mismatch
currentDepName: "13768"
newDepName: "13868"

WARN: Error updating branch: update failure

Another example shows the same behavior:

currentDepName: "22604"
newDepName: "33604"

In both cases, the new version appears to have been applied to the depName rather than only to currentValue.

The dashboard IDs (13768 and 22604) do not change, and the Grafana API also returns the correct IDs.

Workaround

Adding an explicit autoReplaceStringTemplate makes the problem disappear:

{
      autoReplaceStringTemplate: "grafanaCom:\n    id: {{depName}}\n    revision: {{newValue}}",
}

With this template, Renovate correctly updates:

grafanaCom:
  id: 13768
  revision: 7

to

grafanaCom:
  id: 13768
  revision: 8

and no depName mismatch occurs.

Additional information
The dependency is extracted correctly.
The custom datasource works correctly.
The Grafana API returns the correct dashboard ID.
The issue only occurs when relying on the default replacement behavior of the regex manager.
Providing an explicit autoReplaceStringTemplate consistently avoids the problem.

This makes me suspect that the default replacement logic for the regex manager is unintentionally mutating depName when currentValue is updated.

Logs (if relevant)

Logs

2026-07-17T18:03:09.477934019Z        "depName": "13768"
2026-07-17T18:03:09.479492065Z DEBUG: depName mismatch (repository=Boemeltrein/TalosCluster, packageFile=clusters/main/kubernetes/core/blocky/app/grafanadashboard.yaml, branch=renovate/13768-8.x)
2026-07-17T18:03:09.479510329Z        "manager": "regex",
2026-07-17T18:03:09.479515509Z        "currentDepName": "13768",
2026-07-17T18:03:09.479517643Z        "newDepName": "13868"
2026-07-17T18:03:09.480141545Z  WARN: Error updating branch: update failure (repository=Boemeltrein/TalosCluster, branch=renovate/13768-8.x)

2026-07-17T18:03:09.511325276Z DEBUG: Starting search at index 448 (repository=Boemeltrein/TalosCluster, packageFile=clusters/main/kubernetes/observability/smartctl-exporter/app/grafanadashboard.yaml, branch=renovate/22604-3.x)
2026-07-17T18:03:09.511357296Z        "depName": "22604"
2026-07-17T18:03:09.511501158Z DEBUG: Found match at index 448 (repository=Boemeltrein/TalosCluster, packageFile=clusters/main/kubernetes/observability/smartctl-exporter/app/grafanadashboard.yaml, branch=renovate/22604-3.x)
2026-07-17T18:03:09.511516747Z        "depName": "22604"
2026-07-17T18:03:09.512445932Z DEBUG: depName mismatch (repository=Boemeltrein/TalosCluster, packageFile=clusters/main/kubernetes/observability/smartctl-exporter/app/grafanadashboard.yaml, branch=renovate/22604-3.x)
2026-07-17T18:03:09.512454748Z        "manager": "regex",
2026-07-17T18:03:09.512458415Z        "currentDepName": "22604",
2026-07-17T18:03:09.512460939Z        "newDepName": "33604"
2026-07-17T18:03:09.512888492Z  WARN: Error updating branch: update failure (repository=Boemeltrein/TalosCluster, branch=renovate/22604-3.x)

[maxbrunet]

Having what I believe to be the same problem, it used to work, but recently stopped working

autoReplaceStringTemplate recently started to produce newDepName that look like {{depName}}@{{depName}} for a JSONata custom manager

DEBUG: depName mismatch (branch="renovate/quay.io-prometheus-busybox")
{
  "manager": "jsonata",
  "packageFile": ".goreleaser.yml",
  "currentDepName": "quay.io/prometheus/busybox",
  "newDepName": "quay.io/prometheus/busybox@quay.io/prometheus/busybox"
}

Extract of the config:

{
  "customManagers": [
    {
      "description": "Update base image in .goreleaser.yml",
      "customType": "jsonata",
      "fileFormat": "yaml",
      "managerFilePatterns": ["/(^|/)\\.goreleaser\\.ya?ml$/"],
      "matchStrings": [
        "kos.$match(base_image, /^(.+?)(?::(.+?))?(?:@(sha256:.+))?$/).{ 'depName': groups[0], 'currentValue': groups[1], 'currentDigest': groups[2] }"
      ],
      "autoReplaceStringTemplate": "{{depName}}{{#if newValue}}:{{newValue}}{{/if}}{{#if newDigest}}@{{newDigest}}{{/if}}",
      "datasourceTemplate": "docker",
      "depTypeTemplate": "kos.base_image",
      "versioningTemplate": "docker"
    }
  ]
}

Full config: maxbrunet/prometheus-elasticache-sd@67aab3b/renovate.json#L49-L63

Last working PR: maxbrunet/prometheus-elasticache-sd#1311 (Renovate v43.235.0)

Could that be caused by this PR?

• fix(custom/jsonata): support autoReplaceStringTemplate #43535

It says "support", but I had it working 🙃

Other recent discussion mentioning problems with depName mismatch, but likely unrelated:

• Custommanager jsonata does not support packageRules.overrideDepName #44688

[RahulGautamSingh]

Looking into it

[RahulGautamSingh]

Thanks both, there are actually two different bugs here that produce the same depName mismatch symptom, and only one of them is the same root cause.

1. The JSONata case (@maxbrunet) is regression from fix(custom/jsonata): support autoReplaceStringTemplate #43535.

Before that PR the JSONata custom manager ignored autoReplaceStringTemplate; the PR made it honor it. The problem is that JSONata matches structured data, so it never sets a replaceString spanning the whole token. When only the digest changes, replaceString falls back to just the currentDigest sub-token, but the template regenerates the entire depName:value@digest reference. So the full reference gets written in place of the digest token, duplicating the name. Hence we get busybox@busybox.

The regex manager avoids this because it sets replaceString to the whole match, so the template replaces whole-token-for-whole-token.

Fix: only apply the template as a whole-string replacement when replaceString actually spans the region the template regenerates (i.e. the manager provided a full-match replaceString, or rendering the template at the current state reproduces replaceString). Otherwise fall back to the existing per-field replacement, which updates the digest/value without touching depName. That keeps the valid JSONata value-reshaping cases working while fixing the duplication.

2. The regex case in the original report (@Boemeltrein) is separate and, pre-existing.

This one uses no autoReplaceStringTemplate, so it doesn't go through the #43535 code path at all. Here the default replacement does replace(currentValue, newValue) on the matched string, and the first occurrence of currentValue happens to be inside the numeric depName:

• revision: 7 → the 7 in id 13768 is replaced first → 13868
• revision: 22 → the 22 in id 22604 is replaced first → 33604

That collision logic predates #43535 (it's from 2020). Adding an explicit autoReplaceStringTemplate works around it because it stops relying on the substring replace, which is why your workaround helps.

A fix for #1 is ready and I have tested it locally; I'll open a PR soon.

#2 needs a separate fix I will discuss once I get some time to think/test of a fix.