Skip to content

fix(terminal): yield single-line buffers so end marker is observed - #2111

Closed
Solaris-star wants to merge 1 commit into
FoundationAgents:mainfrom
Solaris-star:fix/2110-terminal-end-marker-hang
Closed

fix(terminal): yield single-line buffers so end marker is observed#2111
Solaris-star wants to merge 1 commit into
FoundationAgents:mainfrom
Solaris-star:fix/2110-terminal-end-marker-hang

Conversation

@Solaris-star

Copy link
Copy Markdown

Summary

Terminal.run_command() hung forever on Linux/WSL2 because _read_and_process_output used:

*lines, tmp = output.splitlines(True)

When the buffer is a single newline-terminated line (the common case for the end-of-command marker), that unpack moves the only line into tmp and leaves lines empty — so the marker check never runs and the loop waits for a next byte that never arrives.

Every Engineer2._think() starts with await self.terminal.run_command("pwd"), so this deadlocks the agent before any LLM call.

Change

Treat a buffer that already ends with \n/\r as a complete line to yield. Keep incomplete fragments in tmp only when they lack a trailing newline.

Test plan

  • Unit regression documenting the broken unpack vs correct handling of a lone marker line
  • Manual: await Terminal().run_command("pwd") returns promptly on Linux/WSL2

Fixes #2110

`*lines, tmp = output.splitlines(True)` hid a lone newline-terminated
line in `tmp`, so the end-of-command marker was never checked and
`run_command` hung forever on Linux/WSL2.

Fixes #2110
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Terminal.run_command() hangs indefinitely on Linux/WSL2 — end-of-command marker never yielded from splitlines/tuple-unpack

1 participant