Forgejo PR merge intermittently 500s on a broken sparse-checkout merge workdir #202

New issue

Closed

opened 2026-06-04 06:40:49 +00:00 by coilysiren · 1 comment

coilysiren commented

2026-06-04 06:40:49 +00:00

Owner

Forgejo PR merge intermittently 500s on a broken sparse-checkout workdir

Merging a PR via the API (POST /api/v1/repos/<owner>/<repo>/pulls/<n>/merge) returned HTTP 500 on the first attempt, then succeeded unchanged on an immediate retry. The failure was server-side, in Forgejo's merge working copy.

Observed

First attempt (coily ops forgejo pr merge --repo coilyco-flight-deck/agentic-os --number 150 --method squash):

HTTP 500: git commit [...:docs/features-md-doctrine -> ...:main]: exit status 1
On branch base
You are in a sparse checkout with 7% of tracked files present.

Changes not staged for commit:
	deleted:    .agents/skills/.../invocation.md
	deleted:    AGENTS.md
	deleted:    README.md
	deleted:    agentic_os/check_documentation_layout.py
	... (every tracked file shown as deleted) ...
no changes added to commit

Retry with --method merge succeeded; PR #150 is merged.

Read

Forgejo's per-merge temp working directory came up as a sparse checkout with only ~7% of files materialized, so the merge commit saw every absent file as a deletion and git commit bailed. Looks like a stale/corrupt merge workdir or a core.sparseCheckout leak in the Forgejo pod, not anything about the PR (same PR merged seconds later).

Impact

Intermittent - any PR merge through the API or web UI can hit it. Self-clears on retry so far, but it is a real flake on the merge path.

Next steps

Inspect the Forgejo pod's merge temp dir (data/tmp/local-repo/ or the configured [repository.local] LOCAL_COPY_PATH) for stale sparse-checkout state; clear it.
Check whether git config in the served repos / Forgejo's git env sets core.sparseCheckout.
Consider forgejo doctor checks (coily ops forgejo doctor check).
If it recurs, capture the failing run and the pod's git workdir state.

Surfaced while merging coilyco-flight-deck/agentic-os#150 on 2026-06-03.

## Forgejo PR merge intermittently 500s on a broken sparse-checkout workdir Merging a PR via the API (`POST /api/v1/repos/<owner>/<repo>/pulls/<n>/merge`) returned HTTP 500 on the first attempt, then succeeded unchanged on an immediate retry. The failure was server-side, in Forgejo's merge working copy. ### Observed First attempt (`coily ops forgejo pr merge --repo coilyco-flight-deck/agentic-os --number 150 --method squash`): ``` HTTP 500: git commit [...:docs/features-md-doctrine -> ...:main]: exit status 1 On branch base You are in a sparse checkout with 7% of tracked files present. Changes not staged for commit: deleted: .agents/skills/.../invocation.md deleted: AGENTS.md deleted: README.md deleted: agentic_os/check_documentation_layout.py ... (every tracked file shown as deleted) ... no changes added to commit ``` Retry with `--method merge` succeeded; PR #150 is merged. ### Read Forgejo's per-merge temp working directory came up as a **sparse checkout with only ~7% of files materialized**, so the merge commit saw every absent file as a deletion and `git commit` bailed. Looks like a stale/corrupt merge workdir or a `core.sparseCheckout` leak in the Forgejo pod, not anything about the PR (same PR merged seconds later). ### Impact Intermittent - any PR merge through the API or web UI can hit it. Self-clears on retry so far, but it is a real flake on the merge path. ### Next steps - Inspect the Forgejo pod's merge temp dir (`data/tmp/local-repo/` or the configured `[repository.local] LOCAL_COPY_PATH`) for stale sparse-checkout state; clear it. - Check whether `git config` in the served repos / Forgejo's git env sets `core.sparseCheckout`. - Consider `forgejo doctor` checks (`coily ops forgejo doctor check`). - If it recurs, capture the failing run and the pod's git workdir state. Surfaced while merging coilyco-flight-deck/agentic-os#150 on 2026-06-03.

coilysiren added the

priority

label

2026-06-17 07:04:48 +00:00

coilysiren commented

2026-06-17 08:22:38 +00:00

Author

Owner

Backlog burndown 2026-06-17: closing low-priority (P3/P4) to bring the open count to a manageable level. Nothing lost — reopen if this resurfaces. Batch tag: burndown-2026-06.

Backlog burndown 2026-06-17: closing low-priority (P3/P4) to bring the open count to a manageable level. Nothing lost — reopen if this resurfaces. Batch tag: `burndown-2026-06`.

coilysiren

2026-06-17 08:22:38 +00:00