hunk diff silently fails to register a session for large diffs; daemon drops oversized registration with no error

[gppeixoto]

Summary

On macOS with hunk 0.17.0, running hunk diff against a large multi-file changeset opens the TUI correctly, but the live session is never registered with the session daemon. hunk session list stays empty and a direct POST /session-api {"action":"list"} returns {"sessions":[]} for the entire lifetime of the TUI (observed for 6+ minutes). Small diffs register normally.

The failure is silent: the daemon logs nothing, and the TUI gives no indication that agent/session brokering is unavailable. The daemon process is not killed or restarted (its PID is stable throughout).

The trigger correlates with the total size of the diff content included in the registration payload, not with the ref/target argument. It appears the registration message exceeds the daemon's payload cap (introduced in 0.13.1: "bounded daemon memory by capping payload/message sizes") and is dropped without an error.

Environment

• hunk: 0.17.0 (Homebrew, /opt/homebrew/Cellar/hunk/0.17.0)
• OS: macOS 26.5.1 (build 25F80), Darwin 25.5.0
• Arch: arm64 (Apple Silicon)
• Terminal: ghostty
• Daemon: default 127.0.0.1:47657

Steps to reproduce

In a throwaway git repo, create a changeset whose total diff content is ~12 MB spread across several files (each file individually moderate in size, so it is not collapsed as "too large to display"):

d=$(mktemp -d); cd "$d"
git init -q && git config user.email t@t.t && git config user.name t
echo seed > s.txt && git add -A && git commit -qm base
python3 -c "
for i in range(15):
    with open(f'f{i}.txt','w') as fh:
        fh.write('A'*800000 + '\n')   # one ~800 KB line per file
"
git add -A && git commit -qm big

# terminal 1: ensure a daemon is running
hunk daemon serve

# terminal 2: open the diff
hunk diff HEAD~1

Then, while the TUI is open, in a third terminal:

hunk session list
# -> "No active Hunk sessions."
curl -s -X POST http://127.0.0.1:47657/session-api \
  -H 'Content-Type: application/json' -d '{"action":"list"}'
# -> {"sessions":[]}

Expected

The running hunk diff HEAD~1 TUI registers a session, visible in hunk session list, as it does for smaller diffs.

Actual

No session is ever registered. hunk session list stays empty for the full lifetime of the TUI. The daemon logs nothing and keeps running (same PID).

Isolation / evidence

All runs below use a real PTY (script -q /dev/null hunk ...), the correct Content-Type: application/json header on the probe, and the same long-lived daemon (PID unchanged across every run).

It scales with cumulative diff content, not the argument. Same 15-file recipe, varying the number of ~800 KB-line files:

files (each ~800 KB line)	total diff content	session registered?
1, 3, 6	~0.8–5 MB	yes
7–10	~6–8 MB	yes (near boundary)
12, 15	~10–12 MB	no (deterministic, 3/3)

It is not the ref/target argument. These all register fine: hunk diff, hunk diff HEAD, hunk diff HEAD~1, hunk diff HEAD~5, hunk diff --staged, hunk show, hunk show HEAD, and pathspec-filtered small diffs. A single very large file (e.g. one 1.2 MB line, or files of 2–19 MB) also registers, apparently because such files are collapsed/truncated and their content is left out of the payload. The failure needs several moderately large file contents that all get included and sum past the cap.

The daemon is never killed. Across ~15 launches the listening PID on 47657 stayed constant before and after each failing hunk diff. When hunk diff is the first hunk command in a shell, it auto-launches its own daemon (cf. #502), which can look like a "replacement" but is not a kill.

Nothing is logged. hunk daemon serve stderr shows only the two startup lines; no reject/close/payload/size message appears when a registration is dropped.

Suspected cause

The session-registration payload embeds diff content per file. When the serialized message exceeds the daemon's cap (0.13.1), the daemon drops it, but neither the daemon nor the TUI reports this, so hunk session list is silently empty. The actionable gap is the silent failure: either raise/stream the registration payload, or reject it visibly (extending #180's "reject incompatible registrations more clearly" to oversized payloads) so agents and users know brokering is unavailable.

Notes

• Could not find an existing issue for this. Closest are Windows: hunk diff auto-launches daemon with invalid Bun argv #502 (Windows, invalid Bun argv) and Daemon loses track of live sessions after laptop sleep / lid-close #311 (session loss after sleep), both different.