[Bug]: Gitea WIP PRs are incorrectly shown as having merge conflicts

[batalyse-gmbh]

Before submitting

• I searched existing issues and did not find an exact duplicate.
• I included enough detail to investigate the problem.

Area

apps/server (Forgejo/Gitea status mapping, surfaced in the PR UI)

Steps to reproduce

1. Connect a Gitea repository through T3 Code's source-control integration.
2. Open a PR whose branch has no merge conflicts, with a title prefixed by WIP: (Gitea's work-in-progress/draft convention).
3. Confirm on Gitea that merging is blocked because the PR is work in progress.
4. View the PR status in T3 Code.

These steps describe the reported behavior. The investigation below verified the source-code mechanism; it did not perform a fresh live reproduction.

Expected behavior

T3 Code shows the PR as draft/work in progress without claiming that it has merge conflicts. A PR blocked for another reason, or still being checked, should likewise not be labeled conflicting unless there is evidence of an actual conflict.

Actual behavior

T3 Code reports a merge conflict even though the PR is blocked by its WIP: status.

Impact

Minor bug or occasional failure: misleading status suggests unnecessary conflict resolution and obscures the actual merge blocker.

Source-code evidence

At upstream T3 Code commit 31a9da179ed0763335f05681c577474aec5d2309, forgejoChangeRequest recognizes draft status separately but translates every mergeable: false into "conflicting":

isDraft: pr.draft ?? /^(?:\[WIP\]|WIP:)/i.test(pr.title),
mergeability:
  pr.mergeable === undefined ? "unknown" : pr.mergeable ? "mergeable" : "conflicting",

Gitea's PullRequest.Mergeable returns false for work-in-progress PRs, conflict checks still running, and conflict-check errors, as well as actual conflicts. Its API converter exposes that result as mergeable.

This establishes that the API boolean is insufficient evidence of a conflict. Simply suppressing conflicts on every draft would also hide genuine conflicts in draft PRs; the mapping needs to preserve that distinction.

Version or commit

Source inspection: upstream main at 31a9da179ed0763335f05681c577474aec5d2309 (2026-10-03).
Locally installed CLI reports t3 v0.0.44; the running app build was not independently confirmed.

Environment

Gitea source-control integration. Gitea server version and browser/desktop build were not collected.

Related reports

• [Bug]: Refused merge tells you to check write access when the branch only needs a review #13065 and fix(web): say why a merge was refused #13066 concern misleading failed-merge messages when GitHub branch rules require reviews. This report concerns the Gitea status mapping before a merge attempt.
• feat(source-control): support Forgejo and Gitea with fj and tea #11436 introduced Forgejo/Gitea support and addressed legacy WIP draft-title recognition; the false-to-conflicting mapping remains in the inspected main revision.

Workaround

Open the PR on Gitea to inspect the actual merge blocker.

[juliusmarminge]

Note

Grok responding on behalf of Julius.

Triage

Thanks @batalyse-gmbh for the clear write-up and the links into the Gitea source! This is a bug in T3 Code's Forgejo/Gitea mergeability mapping, and it's still present on main at 31a9da17. Nothing has changed it since Forgejo/Gitea support landed in #11436 (merged), and no open pull request fixes it.

What happens

forgejoChangeRequest in apps/server/src/pullRequest/forgejoPullRequestJson.ts turns every mergeable: false into "conflicting", and the list, summary, and detail views all go through that function. Gitea and Forgejo set draft from the work-in-progress title (WIP: / [WIP], or the instance's configured prefixes) and set mergeable from PullRequest.Mergeable. That value is false in four cases: the conflict check is still running, the check errored, the pull request is a work in progress, or there's a real conflict. The public pull-request object doesn't include the internal status or conflicted_files, so mergeable: false isn't evidence of a conflict. mergeable: true does mean the check finished and nothing blocked the merge.

Draft detection works for your case. Current servers always send draft, so a WIP: pull request is stored as a draft, and the list's conflict badge is hidden for drafts. The false "conflicting" value still takes precedence everywhere else:

• The detail header and the thread row offer Resolve conflicts ahead of the draft/ready action.
• The thread tooltip says the draft conflicts with its base.
• Merge-readiness and blocked-on-author ranking treat it as a conflict rather than a draft.
• A watched pull request wakes with "The branch now conflicts with …".

A pull request that isn't a draft also gets the list's conflict badge while its check is still running or after the check errors.

Likely fix area

As you pointed out, hiding conflicts on every draft would also hide a draft that really does conflict, and it wouldn't fix the running and errored cases. GitLab already avoids this by reading has_conflicts separately and leaving an unfinished check as "unknown". One option is to map mergeable: false to "unknown" and keep true as "mergeable". Real conflicts on these hosts would then show as unknown until the API exposes them. Forgejo has an open request for conflicted_files: forgejo/forgejo#10796. A maintainer will decide on the fix direction.

Related, not duplicates: #14296 (open) is the Forgejo delete-branch merge bug, and #13065 (open, with open PR #13066) covers GitHub's "merge refused" message.