Fix two chat-history bugs in gr.ChatInterface and gr.load_chat

[abidlabs]

Fixes #10823
Fixes #11331

1. history is treated differently for streaming and non-streaming chat functions (#10823)

Mutating history inside a gr.ChatInterface chat function changed the conversation for a non-streaming function and was silently dropped for a streaming one. _append_message_to_history() rebinds history to a new list, and the two paths reach it at different points relative to running the user's function:

• _submit_fn awaits self.fn(...) first, then appends — a mutation inside the fn lands on the list that is then copied, so it survives.
• _stream_fn creates the generator (whose body has not run yet), appends the user message — rebinding history — and only then advances the generator. The generator mutates the original list, which is no longer the one being yielded, so the mutation is dropped.

non-streaming: [{'role': 'assistant', 'content': 'INJECTED BY FN'},   # note the ordering
                {'role': 'user', 'content': 'hi'},
                {'role': 'assistant', 'content': 'reply'}]
streaming:     [{'role': 'user', 'content': 'hi'},
                {'role': 'assistant', 'content': 'reply'}]

Fix: the chat function gets its own copy of the history (list(history)) in both paths, so mutating it never affects the conversation. This removes the order-dependence rather than relying on it, and matches the documented contract: history is an input, and messages reach the chatbot by being returned or yielded.

Note this also drops the odd non-streaming ordering above, where an injected assistant message landed before the user message that triggered it. For the metadata use case raised in the thread (injecting messages so they persist with save_history=True), the real fix is a supported channel for it — related: #11828.

2. gr.load_chat replays text-encoded files as images (#11331)

format_conversation() inlines a text-encoded file into the prompt on the turn it is sent, but turned every file content part in the history into an image regardless of type:

elif content["type"] == "file":
    new_content.append({"type": "image_url", "image_url": {"url": encode_url_or_file_to_base64(...)}})

So with the default file_types="text_encoded", pasting a large prompt (which becomes a .txt attachment) works on that turn, and then every message after it re-sends the .txt base64-encoded as an image — the payload literally contains "url": "data:text/plain;base64,...". That is the request vllm serve rejects with "model is not multimodal", matching the reported sequence exactly: paste long text (works) → type something short (fails). It also explains why file_types=[] made the error go away: no attachment, so nothing to replay.

Fix: text-encoded files in the history are inlined as text, the same as when first sent. Images still go out as image_url. The extension check and the ## filename\ncontents formatting are now shared between the two paths so they cannot drift again, and the check also excludes http(s) URLs, which Path(...).read_text() could not have handled anyway.

Verification

$ python -m pytest test/test_chat_interface.py test/test_external.py -q
76 passed

• test_history_mutation_in_fn_is_ignored_consistently (new) fails on main at assert non_streaming_history == expected. It is an async test and pytest-asyncio is not installed in my local env, so pytest cannot collect it here (test_example_caching_lazy, an existing async test in the same file, fails locally for the same reason — both are fine in CI); I ran the body directly under asyncio.run() to confirm.
• test_format_conversation_replays_text_files_as_text (new) fails on main with assert [{'type': 'im...}] == [{'type': 'te...}], and also pins that a .png in the history is still sent as image_url.
• The 3 remaining local failures are the pre-existing test_load_chat_* tests, which need openai (not installed in my env).

End-to-end for #11331, against a local stand-in for vllm serve that rejects image content the way a non-multimodal model does:

before:  payload content types: ['image_url', 'text', 'text']
         BadRequestError: 400 - 'Model Qwen/Qwen3-8B is not multimodal, but multimodal input was provided.'
after:   payload content types: ['text', 'text', 'text']
         response: ok

Minimal demos (not committed)

# #10823
import asyncio
import gradio as gr


def echo_nonstreaming(message, history):
    history.append({"role": "assistant", "content": "INJECTED BY FN"})
    return "reply"


def echo_streaming(message, history):
    history.append({"role": "assistant", "content": "INJECTED BY FN"})
    yield "reply"


async def main():
    _, non_streaming = await gr.ChatInterface(echo_nonstreaming)._submit_fn("hi", [])
    streaming = None
    async for _, streaming in gr.ChatInterface(echo_streaming)._stream_fn("hi", []):
        pass
    print("consistent:", non_streaming == streaming)


asyncio.run(main())

# #11331
from pathlib import Path
from gradio.external import format_conversation

pasted = Path("pasted_text.txt")
pasted.write_text("a very long pasted prompt\n" * 50)

history = [  # what the Chatbot holds after a turn where a long prompt was pasted
    {"role": "user", "content": [{"type": "file", "file": {"path": str(pasted)}}]},
    {"role": "assistant", "content": [{"type": "text", "text": "ok"}]},
]

conversation = format_conversation(history, "and now a short one")
print([part["type"] for m in conversation for part in m["content"]])

consistent: False → True, and ['image_url', ...] → ['text', ...]. The demo files were kept untracked and are not part of this PR.

🤖 Generated with Claude Code

[gradio-pr-bot]

🪼 branch checks and previews

•	Name	Status	URL
	Spaces	ready!	Spaces preview
	Website	ready!	Website preview
🦄	Changes	detected!	Details

---

Install Gradio from this PR

pip install https://huggingface.co/buckets/gradio/pypi-previews/resolve/bb0fc95eb2d37796f2ef222747ab0c389e95b65a/gradio-6.24.0-py3-none-any.whl

Install Gradio Python Client from this PR

pip install "gradio-client @ git+https://github.com/gradio-app/gradio@bb0fc95eb2d37796f2ef222747ab0c389e95b65a#subdirectory=client/python"

Import Gradio JS Client from this PR via CDN

import { Client } from "https://huggingface.co/buckets/gradio/npm-previews/resolve/bb0fc95eb2d37796f2ef222747ab0c389e95b65a/browser.js";

[gradio-pr-bot]

🦄 change detected

This Pull Request includes changes to the following packages.

Package	Version
gradio	patch

---

• Fix two chat-history bugs in gr.ChatInterface and gr.load_chat

---

Something isn't right?

• Maintainers can change the version label to modify the version bump.
• If the bot has failed to detect any changes, or if this pull request needs to update multiple packages to different versions or requires a more comprehensive changelog entry, maintainers can update the changelog file directly.

[abidlabs]

Before / after Spaces

• Before fix — latest released Gradio (6.24.0), all three behaviours present
• After fix — wheel from this PR at 653e3e383, all three fixed

Both Spaces run byte-identical app.py; only the installed gradio differs, so every difference between the pages is the patch. Each page names which side it is on load by probing behaviour rather than reading the version — the PR wheel carries the same version number as the release it was cut from.

Two plain demos, one per tab.

Tab 1 — #10823. A chat function that appends to the history it was handed, the way you would when assembling a prompt. Send one message.

	before	after
your message appears in the conversation	twice	once

Tab 2 — the review point and #11331. A real gr.load_chat pointed at an in-process OpenAI-compatible stub that accepts every content type and answers 200, so nothing depends on a request being rejected. Attach either example, then send any second message so the first turn is replayed out of the history.

	before	after
the second message	dies with Invalid message for Chatbot component	completes
assistant replies on screen	1 — the second reply is lost	2
the .txt replayed to the model as	image_url, data:text/plain;base64,…	text, as first sent

Driven in Chromium on both sides; those rows are what I observed, not what I expect. Worth one correction to my own earlier reading of the review: on the release the text case dies in Chatbot.postprocess too, not just the image case — the rewritten part is an image_url either way, so both attachments break for the same reason. Locally the same pair produced 5 server tracebacks before the patch and 0 after.

The stub, and the reproduction of the review point, follow @hysts's gradio-13742-remaining.

[hysts]

Both diagnoses look right and the fixes are in the right places. One thing I would like resolved first, and it is one line.

format_conversation() writes its result back into the history it is handed:

message["content"] = new_content
conversation.append(message)

Up to 5.50.0 it built a new dict and left the input alone, so this looks like a slip in the 6.0 rewrite (029034f):

conversation.append({"role": message["role"], "content": message["content"]})

Those dicts are the ones in chatbot_state, so gr.load_chat edits the conversation every time it replays an attachment. Two symptoms:

• The case this PR fixes. The request is now correct, but the attachment in the transcript is replaced by the file's contents as text, and save_history stores that version.
• Images (file_types=["text_encoded", "image"], the value in load_chat's own docstring). Chatbot.postprocess does not accept the substituted part, so the turn dies with ValueError: Invalid message for Chatbot component. Every 6.x release, fine on 5.50.0.

Both are reproducible on the wheel built from this PR: hysts-debug/gradio-13742-remaining. It is a real gr.load_chat pointed at an in-process stub that accepts every content type, so nothing there depends on a request being rejected.

The one-line change is inline. Two smaller notes are also inline, neither blocking.

[hysts]

This is the write-back. {**message, ...} keeps role, metadata and options, so the request goes out unchanged and the history simply stops being edited:

-        message["content"] = new_content
-        conversation.append(message)
+        conversation.append({**message, "content": new_content})

With that, an image in the history survives Chatbot.postprocess, and in the text case the transcript keeps its attachment instead of turning into the file's contents. test_format_conversation_replays_text_files_as_text still passes, and an assert history == before test would pin the property itself.

[hysts]

Two unrelated things about this check, neither blocking.

is_http_url_like sends a remote .txt down the image branch, so it goes out as {"image_url": {"url": "data:text/plain;base64,..."}}, which is the shape this PR is removing. Before, it raised in Path(url).read_text() instead. Reachability is low either way, since uploads land as local cache paths.

Separately, path.lower() is compared against a tuple that still contains .R and .Rmd, so neither plot.R nor plot.r can match and R sources take the base64 image path, which is #11331 for a different extension. They are the only non-lowercase entries in TEXT_FILE_EXTENSIONS. That predates this PR, but this helper is now the one place to fix it.

[hysts]

Nit: the copy is list-level, so history[0]["content"] = ... still reaches the conversation on both paths. "appending to it" would be exact.

[abidlabs]

Thanks @hysts for the review and suggestion! It should be fixed now, I've updated the test Spaces to confirm:

Screen.Recording.2026-08-13.at.10.40.03.AM.mov

[hysts]

Thanks for the update @abidlabs ! LGTM!

[abidlabs]

Thanks for confirming @hysts!