fix(cli): show request progress while streaming-capable operations wait for a response
Why
Generated CLIs show a short-delay spinner on stderr while a request is in flight on an interactive terminal. Operations that declare a streaming response (text/event-stream or JSONL) never started it, because the operation command takes a separate streaming branch. That branch also serves the case where the response comes back as a single JSON body (for example when the request opts out of streaming), so slow model-style calls printed nothing at all until the first byte arrived.
What changed
- The streaming branch in
opcmd.go.stmpl(operation and intent run functions) startsoutput.StartRequestProgressbefore the SDK call, unless the operation has a deferred body. All the existing suppression still applies: machine output modes,--jq, agent mode,--debug,--dry-run, non-interactive and non-TTY output. output.StreamResulttakes an optional stop function and calls it before writing anything: when the first event arrives, when the stream ends empty, or before it falls back to rendering a single non-streamed result. Errors stop the spinner before they are rendered.- Two PTY tests in
request_progress_test.go: the spinner is shown while waiting for the first event and cleared before it is printed, and it is cleared before a non-streamed fallback result. - Review SDK regenerated; changeset added.
Testing
TARGET=review make test-cli: passes, including the new tests.make check-template-cliandmake lint: pass.
Public-safety check
- This change contains no credentials, customer documents, private repository URLs, private filesystem paths, or unredacted private logs.
- Title, body, comments, and commit messages name no customers or customer-derived identifiers, private paths or trackers, or workflow provenance, and are understandable without private context (
.claude/skills/public-repo-communication/SKILL.md). - Generated fixtures and review SDK changes are public-safe.
- I reviewed
git diff --check.
Summary by cubic
Shows the request progress spinner in generated CLIs while streaming-capable operations wait for their first response.
Previously, streaming operations took a separate code path that never started the spinner, so slow calls printed nothing until the first byte arrived. The spinner now starts before the SDK call and clears before the first event is written, when the stream ends empty, or when the response falls back to a single non-streamed result. All existing suppression still applies, and operations with deferred bodies are excluded.
StreamResultnow accepts an optional stop function that runs before any output is written.- Adds PTY tests, generated only for APIs with streaming operations, covering the spinner clearing before the first event and before a non-streamed fallback result.
- Regenerates the review SDK and adds a changeset.