"This pull request is broken due to missing fork information." after pushing

[lenianiva]

Description

I have been using Gitea 1.20.2 for over a year now and recently I started to get "This pull request is broken due to missing fork information" on my pull requests. I can still interact with my repositories in the normal way

I then updated Gitea to 1.21.11 and the issue persisted. I have tried going to the dashboard and:

• Update the '.ssh/authorized_keys' file with Gitea SSH keys.
• Update the '.ssh/authorized_principals' file with Gitea SSH principals.
• Resynchronize pre-receive, update and post-receive hooks of all repositories.

The hooks from a repository suffering this issue are:

$ ls hooks
applypatch-msg.sample	   post-receive.d	  pre-merge-commit.sample    pre-receive	 proc-receive.d		    update.d
commit-msg.sample	   post-update.sample	  prepare-commit-msg.sample  pre-receive.d	 push-to-checkout.sample    update.sample
fsmonitor-watchman.sample  pre-applypatch.sample  pre-push.sample	     pre-receive.sample  sendemail-validate.sample
post-receive		   pre-commit.sample	  pre-rebase.sample	     proc-receive	 update

Gitea Version

1.21.11

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No logs are generated for gitea/log and log in the gitea directory, so I'm not sure what log to include

Screenshots

Git Version

2.44.1

Operating System

NixOS 24.05.20240803.a633d89 (Uakari)

How are you running Gitea?

Using the gitea module from NixOS's configuration.nix

Database

PostgreSQL

[lunny]

Have you tried to refresh multiple times?

[lenianiva]

Have you tried to refresh multiple times?

Do you mean refreshing the browser? It didn't work

[lenianiva]

The problem is gone for now after I merged the branches into each other a bit. I don't know what caused it in the first place.

[i124q2n8]

We are encountering this issue too and I think this might be (in our case) due to aborted requests.

Is it possible that if the server is under heavy load and the user clicks on "Update branch by merge" but doesn't wait for the request to finish that this will break fork information on this PR/branch?

[lunny]

We are encountering this issue too and I think this might be (in our case) due to aborted requests.

Is it possible that if the server is under heavy load and the user clicks on "Update branch by merge" but doesn't wait for the request to finish that this will break fork information on this PR/branch?

What's your Gitea version?

[i124q2n8]

We are encountering this issue too and I think this might be (in our case) due to aborted requests.
Is it possible that if the server is under heavy load and the user clicks on "Update branch by merge" but doesn't wait for the request to finish that this will break fork information on this PR/branch?

What's your Gitea version?

1.23.7

[lunny]

Please help to check
1 If the repository can be visit from server disk
2 If the head repository exist
3 If the base branch and head branch exist
4 If the refs refs/pull/<index>/head exist and the commit id can be visited.

[i124q2n8]

Ty for your feedback. I'll provide the requested information as soon as we encounter the issue again. I think that the answer to all these questions if "yes", because a simple push (e.g. an empty commit) will fix the issue.

Maybe this is helpful too:
When clicking on "Update branch by merge" I usually don't wait for the page to load and navigate away to another page. The last month I always waited for the page to fully load before navigating away and didn't get the bug. (In times where the server was under heavy load this took 2-5 seconds, which is expected)

[i124q2n8]

Hello again. I successfully reproduced the issue. The CPU was maxed out due to other tasks running on the same server. I clicked the "Update branch by merge" button and immediately navigated away (which cancelled the request). After going back to the page I was greeted by "This pull request is broken due to missing fork information.".
(So it really seems to be a timing issue. I am really sure it's not a timeout because waiting on the page works just fine)

I hope the following context helps. I can leave this branch in this state a couple of days if you need me to run some more commands against the repo.

/var/lib/gitea/data/gitea-repositories/org/repo.git/$ cat HEAD
ref: refs/head/master

/var/lib/gitea/data/gitea-repositories/org/repo.git/$ git show-ref refs/heads/123-branch-name
ddc3d99b3530700f1b6e2ad6ec12297338224a1d refs/heads/123-branch-name

/var/lib/gitea/data/gitea-repositories/org/repo.git/$ git cat-file -p ddc3d99b3530700f1b6e2ad6ec12297338224a1d
tree e67d745c1760c1a0d30984d52a3425729499ee8c
parent 21d9d76711db1352d8cc14af230f1c023ebf6cc2
parent a650fe87440646b2f1bbc54c25591e556543cd28
author Foo Bar <foobar@example.org> 1747247763 +0000
committer Foo Bar <foobar@example.org> 1747247763 +0000

Merge branch 'master' into 123-branch-name

/var/lib/gitea/data/gitea-repositories/org/repo.git/refs/pull/1935$ ls
head

/var/lib/gitea/data/gitea-repositories/org/repo.git/refs/pull/1935$ cat head
21d9d76711db1352d8cc14af230f1c023ebf6cc2

/var/lib/gitea/data/gitea-repositories/org/repo.git/refs/pull/1935$ git cat-file -t 21d9d76711db1352d8cc14af230f1c023ebf6cc2
commit

/var/lib/gitea/data/gitea-repositories/org/repo.git/refs/pull/1935$ git cat-file -p 21d9d76711db1352d8cc14af230f1c023ebf6cc2
tree 015a7a48e816eb54d47455d23ba2aa6f883fe102
parent e1f5f31b5cdf1cc5ece6954d819640e7db85da8d
author Foo Bar <foobar@example.org> 1747245578 +0200
committer Foo Bar <foobar@example.org> 1747245578 +0200

Fix

Just some speculation on my end:
I looked at the related go code in pull.go, update.go, merge.go, etc. and saw that you are passing a ctx around. Is it possible that the context is cancelled when the request closes and some functions like cmd.RunStdString don't run to completion?
Maybe this bug can be easily reproduced by adding a sleep to the UpdatePullRequest method, so that you have more time to cancel the request in your browser.

[lunny]

I sent the PR #34509 to try to fix the problem. Can you try that patch?

[i124q2n8]

I tried to reproduce the bug locally with 1.23.7 and 1.23.8 for the last 3 hours, but it seems like I cannot recreate the exact conditions. Sadly we cannot easily deploy the patch remotely.

I don't have much time the next couple of weeks. I'll try again when I got time.

If you think the changes in #34509 are a step in the right direction (regardless of whether they'll fix the issue or not) we can wait for a new release that we can deploy to our production environment and report back.