merge_streaming_text drops characters for pure-delta streaming producers
Summary
merge_streaming_text (used by MarkdownStreamController.append) corrupts streamed
text when the producer emits pure incremental deltas. Whenever a new chunk's
leading character equals the trailing character of the already-accumulated content,
that character is silently dropped.
This surfaces in Feishu streaming cards as missing digits/characters, e.g. 404
rendered as 40, an account id 2100138470 rendered as 210138470, and
2026-07-23 rendered as 2026-07-2.
Version
lark-channel-sdk == 1.2.0 (latest on PyPI; only 1.0.0 / 1.1.0 / 1.2.0 exist, so
there is no newer release to upgrade to).
Minimal Reproduction
Verified directly against the SDK's own function:
from lark_channel.channel.outbound.streaming.merge_text import merge_streaming_text as orig
orig("40", "4") # => "40" expected "404" (hits `prev.startswith(chunk)`, drops "4")
orig("210", "0") # => "210" expected "2100" (trailing "0" overlaps leading "0", dropped)
Actual output:
orig 40+4 => '40'
orig 210+0 => '210'
Expected vs. Actual
Input (prev, chunk) |
Expected |
Actual |
Dropped |
Branch hit |
("40", "4") |
"404" |
"40" |
trailing 4 |
prev.startswith(chunk) |
("210", "0") |
"2100" |
"210" |
one 0 |
longest suffix/prefix overlap |
Root Cause
lark_channel/channel/outbound/streaming/merge_text.py:
def merge_streaming_text(prev: str, chunk: str) -> str:
if not chunk:
return prev
if not prev:
return chunk
if chunk.startswith(prev):
return chunk
if prev.startswith(chunk): # (1) drops a delta that is a prefix of prev
return prev
# Find the longest suffix of prev that is a prefix of chunk.
max_overlap = min(len(prev), len(chunk))
for size in range(max_overlap, 0, -1):
if prev[-size:] == chunk[:size]: # (2) drops the "overlap" region
return prev + chunk[size:]
return prev + chunk
The function tries to auto-detect accumulated vs. delta vs. mixed producers from the
text content alone. Two of its heuristics are invalid for pure delta producers:
if prev.startswith(chunk): return prev — a single-character delta such as "4"
easily matches the tail state and gets discarded.
- The "longest suffix-of-prev that is a prefix-of-chunk" dedup deletes the overlap,
so any delta whose first char equals the accumulated tail loses that char.
As a result, repeated digits (00, 404) and boundary characters are the most
frequently corrupted.
Impact
Google ADK's LiteLlm streaming yields pure deltas (each SSE event carries only the
newly generated text, not the running total):
# google/adk/models/lite_llm.py
elif isinstance(chunk, TextChunk):
text += chunk.text
yield _message_to_generate_content_response(
ChatCompletionAssistantMessage(role="assistant", content=chunk.text), # delta only
is_partial=True,
model_version=part.model,
)
Any integration that forwards these deltas to MarkdownStreamController.append will
lose characters in the rendered card.
Suggested Fix
Do not infer the producer mode from content. Provide an explicit mode (e.g.
append_mode="delta" | "accumulated") so delta producers use plain concatenation:
def merge_streaming_text(prev: str, chunk: str) -> str:
return (prev or "") + (chunk or "") # correct for pure-delta producers
Workaround
Monkeypatch the merge function to a plain concatenation before streaming:
from lark_channel.channel.outbound.streaming import markdown_stream
def _concat(prev: str, chunk: str) -> str:
return (prev or "") + (chunk or "")
markdown_stream.merge_streaming_text = _concat
Verified after patching:
orig 40+4 => '40' # buggy
orig 210+0 => '210' # buggy
patched 40+4 => '404' # correct
patched 210+0 => '2100' # correct
merge_streaming_textdrops characters for pure-delta streaming producersSummary
merge_streaming_text(used byMarkdownStreamController.append) corrupts streamedtext when the producer emits pure incremental deltas. Whenever a new chunk's
leading character equals the trailing character of the already-accumulated content,
that character is silently dropped.
This surfaces in Feishu streaming cards as missing digits/characters, e.g.
404rendered as
40, an account id2100138470rendered as210138470, and2026-07-23rendered as2026-07-2.Version
lark-channel-sdk == 1.2.0(latest on PyPI; only1.0.0 / 1.1.0 / 1.2.0exist, sothere is no newer release to upgrade to).
Minimal Reproduction
Verified directly against the SDK's own function:
Actual output:
Expected vs. Actual
(prev, chunk)("40", "4")"404""40"4prev.startswith(chunk)("210", "0")"2100""210"0Root Cause
lark_channel/channel/outbound/streaming/merge_text.py:The function tries to auto-detect accumulated vs. delta vs. mixed producers from the
text content alone. Two of its heuristics are invalid for pure delta producers:
if prev.startswith(chunk): return prev— a single-character delta such as"4"easily matches the tail state and gets discarded.
so any delta whose first char equals the accumulated tail loses that char.
As a result, repeated digits (
00,404) and boundary characters are the mostfrequently corrupted.
Impact
Google ADK's LiteLlm streaming yields pure deltas (each SSE event carries only the
newly generated text, not the running total):
Any integration that forwards these deltas to
MarkdownStreamController.appendwilllose characters in the rendered card.
Suggested Fix
Do not infer the producer mode from content. Provide an explicit mode (e.g.
append_mode="delta" | "accumulated") sodeltaproducers use plain concatenation:Workaround
Monkeypatch the merge function to a plain concatenation before streaming:
Verified after patching: