Repository navigation
Random error in the prune remote step #4198
Description
Description
We have several workflows running on a 6-hour schedule that have been working without issues for months using peter-evans/create-pull-request@271a8d0340265f705b14b6d32b9829c1cb33d45e # v7.0.8 action.
Recently, we started to observe random failures across all of them, usually not more than one failure per day(1 out of 4 fails). These seem to be completely random. In all the cases I checked, there was no pull request open with the same branch name, nor would the action create a pull request(no change).
The error always occurs in the Checking the base repository state step. We have seen two different cases:
Most common:
Checking the base repository state
/usr/bin/git symbolic-ref HEAD --short
master
Working base is branch 'master'
/usr/bin/git remote prune origin
remote: Repository not found.
fatal: repository 'https://github.com/REDACTED' not found
Error: The process '/usr/bin/git' failed with exit code 128
Less common:
Checking the base repository state
/usr/bin/git symbolic-ref HEAD --short
master
Working base is branch 'master'
/usr/bin/git remote prune origin
error: RPC failed; HTTP 404 curl 22 The requested URL returned error: 404
fatal: expected flush after ref listing
Error: The process '/usr/bin/git' failed with exit code 128
Extra details
All our workflows run on self-hosted runners, as described above it may or may not create pull requests, depending on changes in another system.
Our action configuration:
- name: Create Pull Request
id: create-pull-request
uses: peter-evans/create-pull-request@271a8d0340265f705b14b6d32b9829c1cb33d45e # v7.0.8
with:
title: REDACTED
body: REDACTED
commit-message: REDACTED
base: ${{ github.event.repository.default_branch }}
branch: REDACTED
token: ${{ steps.app-token.outputs.token }}
sign-commits: true
If you need more details or logs, happy to provide.
P.S.: Thanks a lot for your amazing work in all the GH actions you provide to the community.
Activity
smallprogram commentedon Nov 14, 2025
+1
francescodone commentedon Dec 2, 2025
+1
blalor commentedon Dec 2, 2025
I'm also running into this issue. This feels like a GitHub issue, and I'm probably going to work around it by adding a retry (😢🐼). I haven't seen a regular (if intermittent) problem like this in other workflows or actions.
I've compared the logs of successful and failing runs and I don't see anything untoward. Like @VDVsx, however, I'm also using an app token…
peter-evans commentedon Dec 2, 2025
Thank you for reporting @VDVsx
Is there anyone experiencing this that isn't on self-hosted?
That particular git command was added due to an issue on self-hosted runners:
create-pull-request/src/create-pull-request.ts
Lines 124 to 129 in bc8a47f
blalor commentedon Dec 2, 2025
I'm using a GH-hosted runner, just
ubuntu-latestfor the job that fails most often.peter-evans commentedon Dec 5, 2025
I've released an update in
v7.0.11/v7, that restricts thegit remote prunestep to self-hosted runners only. When I originally introduced that step I didn't know how to restrict it to self-hosted, but I've now found a solution.This should limit the issue to those running on self-hosted.
jpalomaki commentedon Dec 8, 2025
FWIW, while I have not seen this particular error myself, we use ephemeral self-hosted runners (as do many others I imagine, as stacks like ARC, terraform-aws-github-runner and runs-on.com support them), so this code comment isn't always true I presume?
smallprogram commentedon Dec 8, 2025
use github gh cli fixed this error
nobbs commentedon Jan 21, 2026
Also running into this issue randomly on ephemeral self-hosted runners. Any way to disable the prune call?
peter-evans commentedon Jan 21, 2026
I decided to catch errors with
git remote pruneand continue anyway. This should prevent those on ephemeral runners from having occasional issues when the call fails. However, for those using non-ephemeral self-hosted runners, if thegit remote prunecall fails there's a chance thatgit pushwill fail later when the action comes to push the branch.This is now released in
v8.1.0/v8.merrkry commentedon Oct 27, 2026
The prune warning in v8 lets execution continue, but the same transient Git failure can immediately abort the following fetch.
On
v8at5f6978faf089d4d20b00c7766989d076bb2fc7f1, the failure sequence is:git remote prune originreturnsremote: Repository not found.and exit code 128.The code path explains why the warning alone does not provide recovery:
create-pull-request.tscatches only the prune failure.basesupplied,create-or-update-branch.tssubsequently fetches the base branch.GitCommandManager.fetchcallsexeconce, andexeclaunches Git once.pushhas the same lack of retries.The REST retries added in #4298 do not cover these Git subprocesses. Bounded backoff for transient failures at the Git transport methods would cover subsequent fetches as well as prune, while still surfacing persistent failures.
A separate Airflow report documents freshly issued GitHub App tokens briefly failing at the Git HTTPS endpoint. That is a possible trigger here, not a confirmed explanation for this occurrence.