Dataframe stream not rendering

[obda-blum]

Describe the bug

I have a calculation that takes some time and I want to stream the intermediate results of the calculation to a dataframe. When running the calculation the dataframe only correctly streams the first row. Further rows are only shown when clicking on the dataframe.
I tried various configurations with row_count, interactive, ... but none seemed to work.

Edit: Streaming to a markdown works just fine.

Have you searched existing issues? 🔎

• I have searched and found no existing issues

Reproduction

import time
import gradio as gr
import pandas as pd


def stream_dataframe(n_steps: int = 5):
    rows = [
        {"Step": i + 1, "Value": f"Result {i + 1}"} for i in range(n_steps)
    ]
    for i in range(n_steps):
        time.sleep(0.5)  # Simulate some processing time
        yield pd.DataFrame(rows[: i + 1])


with gr.Blocks(title="Streaming Dataframe MWE") as demo:

    result_table = gr.Dataframe(
        row_count=(1, "dynamic"),
        interactive=True,
        label="Results"
    )
    run_btn = gr.Button("Run")

    run_btn.click(stream_dataframe, outputs=[result_table])


if __name__ == "__main__":
    demo.launch()

Screenshot

Logs

System Info

Gradio Environment Information:
------------------------------
Operating System: Linux
gradio version: 6.20.0
gradio_client version: 2.5.0

------------------------------------------------
gradio dependencies in your environment:

anyio: 4.14.2
audioop-lts is not installed.
brotli: 1.2.0
fastapi: 0.139.0
gradio-client: 2.5.0
groovy: 0.1.2
hf-gradio: 0.4.1
httpx: 0.28.1
huggingface-hub: 1.23.0
jinja2: 3.1.6
markupsafe: 3.0.3
numpy: 2.5.1
orjson: 3.11.9
packaging: 26.2
pandas: 3.0.3
pillow: 12.3.0
pydantic: 2.13.4
pydub: 0.25.1
python-multipart: 0.0.32
pytz: 2026.2
pyyaml: 6.0.3
safehttpx: 0.1.7
semantic-version: 2.10.0
starlette: 1.3.1
tomlkit: 0.14.0
typer: 0.26.8
typing-extensions: 4.15.0
uvicorn: 0.51.0
mcp is not installed.
pydantic: 2.13.4
authlib is not installed.
itsdangerous is not installed.


gradio_client dependencies in your environment:

fsspec: 2026.6.0
httpx: 0.28.1
huggingface-hub: 1.23.0
packaging: 26.2
typing-extensions: 4.15.0

Severity

Blocking usage of gradio

[ujwalashet]

I'd like to work on this. I've reproduced the bug locally and I'm currently investigating the root cause in Table.svelte will share findings once I have a fix ready.

[ujwalashet]

I dug into this and found the root cause — sharing here in case it's useful, since I understand PRs from outside contributors are currently paused.

##Root cause

The Dataframe component's virtualized table (js/dataframe/shared/tanstack/virtual.svelte.ts) only calls virtualizer.measure() on the initial 0 -> N row transition:

if (prev_count === 0 && current_count > 0) {
    virtualizer.measure();
}

Every subsequent row-count change calls virtualizer.setOptions({...}), but setOptions() alone does not trigger a re-measure of visible rows — it only updates the virtualizer's internal config. So when streaming rows in one at a time via a generator, the underlying data (values → row_data → rows, via TanStack Table) updates correctly on every step, but the virtualizer's virtual_items (what actually gets rendered) stays frozen after the first row, since it's never told to recalculate again.

I confirmed this with console logging: row_data/rows climbed 0→1→2→3→4→5 in step with the streamed data, while virtual_items went 0→1 and then stayed at 1 for every subsequent update — until a click on the table (which triggers an unrelated scroll/resize code path) coincidentally forced a recalculation and all rows suddenly appeared. That's why clicking the table "fixes" it.

Fix

Re-measure whenever the row count changes at all, not just on first population:

if (current_count !== prev_count) {
    virtualizer.measure();
}

Testing

Verified locally using the minimal reproduction from the issue description. After the fix, all streamed rows render immediately with no user interaction needed, and virtual_items tracks the underlying row count on every update.

Happy to open a PR with this change if outside PRs are being accepted for a fix like this — otherwise hope this saves someone the investigation time.