github-actions: mise-action version+sha256 update fails when a comment mentions the current version ("Error updating branch: update failure")

[dmccaffery]

How are you running Renovate?

Self-hosted, ghcr.io/renovatebot/renovate:44 (44.29.5) via renovatebot/github-action, platform github, with platformCommit: enabled.

Describe the bug

Since #44876, the github-actions manager updates jdx/mise-action's version: and sha256: inputs together (the sha256 is extracted as currentDigest). If the workflow file also contains the current version string in a nearby comment — e.g. a comment documenting which asset the sha256 belongs to — the branch fails every run with only the generic:

WARN: Error updating branch: update failure

Reproduction

# .github/workflows/test.yml
on: push
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: jdx/mise-action@7e36c90d9ab29c415a2384db3006f3ec8a8cc654 # v4.2.4
        with:
          version: v2026.7.3
          # sha256 of the mise-v2026.7.3-linux-x64 binary, from the release's
          # SHASUMS256.txt
          sha256: 06088e84e4514b59fd2b6b17927bcc37aa0ab10020a270868871fb010b92069b

Removing v2026.7.3 from the comment makes the update succeed; adding it back reproduces the failure.

Debug logs

DEBUG: currentDigest not found in string to replace
       "stringToReplace": "v2026.8.4",
       "currentDigest": "06088e84e4514b59fd2b6b17927bcc37aa0ab10020a270868871fb010b92069b"
DEBUG: Starting search at index 15345 (packageFile=.github/workflows/release.yaml)
       "depName": "jdx/mise"
DEBUG: Found currentValue at index 15444
       "currentValue": "v2026.7.3"
DEBUG: Found currentValue at index 15485
       "currentValue": "v2026.7.3"
 WARN: Error updating branch: update failure

Analysis

The dep's replaceString is just the version value, so in doAutoReplace (lib/workers/repository/update/branch/auto-replace.ts) the digest substitution into newString can't apply ("currentDigest not found in string to replace"), and the update falls through to the replaceWithoutReplaceString scan. That loop replaces the first currentValue hit (the version: input), then encounters the second hit (the comment) while valueReplaced is already true, treats it as ambiguity, resets state, and restarts from the next candidate index. Because the comment occurrence sits between the version: and sha256: lines, no starting position can replace exactly one version occurrence plus the digest before tripping the duplicate, so every attempt resets and the update ultimately throws.

Expected behavior

Either tolerate extra occurrences of currentValue once the value+digest pair has been consistently replaced (e.g. attempt confirmIfDepUpdated before discarding on a duplicate hit), or extract a replaceString/autoReplaceStringTemplate spanning the version:…sha256: block so the digest replacement happens inside the template path. Failing that, surfacing the underlying auto-replace error instead of the generic Error updating branch: update failure WARN would make this much easier to diagnose — the failure happens before any platform interaction, but the message reads like a push/permissions problem.

Note the lookup side works correctly (the right newDigest is computed); #44876's integration test covers lookup but not the file rewrite, which is why this wasn't caught.

[RahulGautamSingh]

Sounds legit. PR is welcome with your suggested fix. Thanks!