Skip to content

refactor(runtime): drop unused receiver from handleStream#2539

Merged
dgageot merged 1 commit intodocker:mainfrom
dgageot:extract-stream-processor
Apr 27, 2026
Merged

refactor(runtime): drop unused receiver from handleStream#2539
dgageot merged 1 commit intodocker:mainfrom
dgageot:extract-stream-processor

Conversation

@dgageot
Copy link
Copy Markdown
Member

@dgageot dgageot commented Apr 27, 2026

Summary

handleStream is the chunked-stream aggregator in
pkg/runtime/streaming.go — it consumes an LLM provider's
chat.MessageStream and turns the deltas into an aggregated
streamResult plus events on the events channel.

It was declared as a method on *LocalRuntime, but its body never
touches r. The receiver is a pure artefact of where the file sits.

Drop it, tighten the events channel direction, document why.

What this is, and what it isn't

This is a pure isolation win:

  • handleStream becomes a free function. It is now unit-testable
    with a mock chat.MessageStream alone — no LocalRuntime, team,
    hooks, model store, or any of the other runtime wiring required.
  • events chan Eventevents chan<- Event matches the rest of
    the package's send-only conventions (swapCurrentAgent etc.) and
    documents at compile time that the function never reads.
  • Doc comment now spells out the dependency direction: the loop
    calls into the chunker, never the reverse.

This is not:

  • A behaviour change. Same logic, same events, same return values.
  • A package extraction. streamResult stays unexported in
    pkg/runtime. Lifting this into pkg/runtime/internal/streamproc
    would require inverting the events-channel dependency (Event is
    currently a runtime-defined type), which is a much larger refactor
    and explicitly out of scope here.
  • A function split. handleStream is still ~200 lines doing tool-call
    aggregation, content/reasoning aggregation, usage tracking, and
    finish-reason coercion. Those concerns could be split, but that's
    a separate refactor.

Diff

Two files, six lines of substantive change:

  • pkg/runtime/streaming.go: drop (r *LocalRuntime), tighten
    channel direction, add doc paragraph explaining why.
  • pkg/runtime/fallback.go: drop the r. qualifier at the single
    call site.

streamResult and stripImageContent are unchanged.

Validation

  • mise lint — 0 issues
  • mise test — full suite passes (existing stripImageContent
    table test still works since both functions live in the same
    package)

handleStream is the chunked-stream aggregator that turns an LLM
provider's chat.MessageStream into a streamResult plus a sequence
of events. It was declared as a method on *LocalRuntime, but its
body never touches `r` — the receiver is purely an artefact of
where the file sits. Drop it.

This is a pure isolation win, not a behaviour change:

- handleStream is now a free function, callable (and unit-testable)
  without spinning up a LocalRuntime, a team, hooks, or anything
  else; a mock chat.MessageStream is the only dependency.
- The events parameter tightens from `chan Event` to `chan<- Event`,
  matching the rest of the package's send-only conventions and
  documenting that the function never reads from the channel.
- Doc comment now states the dependency direction explicitly: the
  loop calls into the chunker, never the reverse.
- Only caller (tryModelWithFallback in fallback.go) updated to drop
  the `r.` qualifier.

streamResult and stripImageContent are unchanged. A future
follow-up could lift this into pkg/runtime/internal/streamproc to
enforce the boundary at compile time, but that requires inverting
the events-channel dependency (Event is currently a runtime type)
and is out of scope here.

Assisted-By: docker-agent
@dgageot dgageot requested a review from a team as a code owner April 27, 2026 15:11
@dgageot dgageot merged commit 747d6c5 into docker:main Apr 27, 2026
9 checks passed
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.

2 participants