Prerequisites

• I have read the contribution guidelines
• I have searched for similar issues
• I have read the documentation and wiki

Impacted version

4.44.0, 4.47.0

Deployment mode

Standalone app in incus container

Problem description

Title: git push over SSH and HTTPS hangs indefinitely for packs above ~55KB (JGit PackParser stuck in InputStream.read, size-dependent, transport-independent)

Environment

• GitBucket 4.44.0 and 4.47.0 (both reproduce identically)
• Bundled JGit: 6.10.1.202505221210-r (unchanged between the two GitBucket versions tested, per the agent= string in GIT_TRACE_PACKET output)
• Bundled Apache SSHD: 2.16.0 (4.44.0) / 2.19.0 (4.47.0) — upgrading this had no effect
• JVM: OpenJDK 17.0.14, 52-core host, no memory pressure
• Git client: 2.43.0
• Reproduced over both SSH and HTTPS

Summary

git push hangs indefinitely for a pack once it crosses roughly 55-100 KiB in total size, regardless of transport (SSH or HTTPS), regardless of whether the target ref is new or already exists, and regardless of thin-pack vs. full-pack encoding. The client finishes writing objects normally (Writing objects: 100% ... done) and then receives zero further protocol response from the server — no progress, no error, nothing — until something external eventually kills the connection (SSH: Apache MINA's own idle timeout at 600s; HTTPS: our reverse proxy's read timeout, since GitBucket/Jetty itself never times out or logs anything on that path).

Server-side thread dumps taken repeatedly during the hang (kill -QUIT on the JVM, ~60s apart) show the request thread parked in the identical stack every time, with zero progress between samples:

java.io.InputStream.read(java.base@17.0.14/InputStream.java:218)
org.eclipse.jgit.transport.PackParser.whole(PackParser.java:1061)
org.eclipse.jgit.transport.PackParser.indexOneObject(PackParser.java:983)
org.eclipse.jgit.transport.PackParser.parse(PackParser.java:534)
org.eclipse.jgit.internal.storage.file.ObjectDirectoryPackParser.parse(ObjectDirectoryPackParser.java:168)
org.eclipse.jgit.transport.ReceivePack.receivePack(ReceivePack.java:1559)
org.eclipse.jgit.transport.ReceivePack.receivePackAndCheckConnectivity(ReceivePack.java:1250)
org.eclipse.jgit.transport.ReceivePack.service(ReceivePack.java:2270)
org.eclipse.jgit.transport.ReceivePack.receive(ReceivePack.java:2200)
gitbucket.core.ssh.DefaultGitReceivePack.$anonfun$runTask$6(GitCommand.scala:190)

For the SSH case specifically, GitBucket's log eventually shows:

Detected IdleTimeout after 600218/600000 ms
org.apache.sshd.common.channel.exception.SshChannelClosedException: write(...) - channel already closed
      at org.eclipse.jgit.transport.ReceivePack.close(ReceivePack.java:1963)
      at org.eclipse.jgit.transport.ReceivePack.receive(ReceivePack.java:2210)

— i.e. GitBucket only notices anything is wrong when Apache MINA's own idle timer forcibly kills the session out from under a still-blocked ReceivePack.

What's been ruled out (each individually tested and disproven, not just assumed):

• Reverse proxy in front of SSH — reproduces identically on a direct connection that bypasses it entirely
• GC/heap pressure — jstat -gcutil flat throughout
• CPU-bound work — no busy thread, idle host
• A hung outbound call (e.g. a webhook) — no new/lingering outbound connections from the JVM during the hang
• Apache SSHD version — upgrading GitBucket 4.44.0 → 4.47.0 bumps apache-sshd 2.16.0 → 2.19.0 with no effect; both bundle the same JGit version
• Thin-pack external delta-base resolution — git push --no-thin hangs identically
• New-ref vs. existing-ref creation — pre-creating the target branch via the web UI (so the push is a fast-forward update, not a creation) still hangs identically; conversely, a genuine new-ref push of small content succeeds fine
• Transport — identical hang over SSH and HTTPS

Bisection — this is the part that actually isolates it

Splitting one failing push's exact content in half:

Neither half is a "bad" object — both push cleanly on their own. Only the combined ~104 KiB pack hangs. This points at a total pack-size threshold somewhere between ~55 KiB and ~104 KiB in PackParser, not any specific object, encoding, or transport detail.

Reproduction

1. Create any commit whose full pack (via git push) totals roughly >60 KiB and includes more than a trivial single-file change
2. git push (SSH or HTTPS) to a GitBucket 4.44.0/4.47.0 instance
3. Client finishes "Writing objects: 100%"; server sends nothing back; connection eventually dies via whatever external timeout exists on that transport

Notes

This doesn't appear to match existing large-repository issues in this tracker (e.g. #121, #1092, #2502) — those involve multi-GB repositories timing out over many minutes during activity-log/indexing work. This is a ~104 KiB pack, fails within seconds of the pack being fully sent, and is 100% reproducible.

Given it reproduces identically over both SSH and HTTPS, this looks like a bug in JGit's PackParser/ReceivePack itself rather than anything GitBucket-specific — a corresponding issue will be filed with eclipse-jgit/jgit and linked here once opened.