The server echoes a sent message part by part. The reducer replaced an
optimistic part with its server echo only while the FIRST part of the
message was still optimistic, so once the text echo had landed the file
echo no longer qualified and was appended instead: an attached image
showed twice until the next page fetch rewrote the parts.
Any remaining optimistic part of the same type is now a replacement
candidate. The scan only runs when a part with a new id arrives, which is
once per part during assistant streaming.
Testing: reducer test extended past the first echo to the file echo; ui
type-check and lint; verified the event order against a live OpenCode
(message, text part, file part within ~70ms of the accepted request).
Bohdan Triapitsyn
4915658de1