[Alek99]

All Submissions:

• Have you followed the guidelines stated in CONTRIBUTING.md file?
• Have you checked to ensure there aren't any other open Pull Requests for the desired changed?

Type of change

• Bug fix (non-breaking change which fixes an issue)

Changes To Core Features:

• Have you added an explanation of what your changes do and why you'd like us to include them?

EventNamespace.emit_update wrapped the socket emit in asyncio.create_task(...) and then immediately awaited it, with a comment claiming the task "prevents the update from being blocked behind other coroutines". Awaiting a freshly created task blocks the caller exactly like awaiting the coroutine directly — the wrapper never provided any concurrency; it only added per-update task creation/scheduling overhead (plus an f-string task name with a time.time() call). Since emit_update runs while the state lock is held (via modify_state / the event processor's emit_delta path), that overhead was paid on every outgoing state update.

The one load-bearing side effect of the wrapper (caught by test_yield_state_update[click_yield_interim_value] on the first iteration of this PR): awaiting a fresh task forces an event-loop tick, which lets engineio's per-connection writer task flush the queued packet before the caller resumes. sio.emit itself can complete without ever suspending (the packet is only put on a non-full queue), so a sync handler that blocks the loop right after yielding (e.g. yield → time.sleep(...)) would otherwise hold the interim update hostage in the write queue. The fix keeps that guarantee explicitly with await asyncio.sleep(0) after the emit, with a regression note explaining why the tick must stay.

Micro-benchmark (Python 3.13, replicating the exact await patterns with a stand-in emit coroutine, 20k iterations after warmup):

variant	per update
before: await asyncio.create_task(emit(...), name=f"...{time.time()}")	9.19 µs
after: await emit(...) + await asyncio.sleep(0)	4.84 µs

1.9x less overhead per outgoing update. A writer-task ordering simulation confirms the interim packet is flushed before a loop-blocking caller resumes in both the old and new versions (and is not flushed with a plain await emit(...) alone — which is why the sleep(0) is load-bearing).

Linear: ENG-10110

🤖 Generated with Claude Code

https://claude.ai/code/session_01Sns7EuBPYvfGCxRSRZ1bUx

[greptile-apps]

Greptile Summary

This PR reduces per-update websocket emit overhead while keeping interim updates flushable. The main changes are:

• Directly awaits EventNamespace.emit_update socket emits instead of wrapping them in a task.
• Adds an explicit event-loop yield after each emit.
• Adds a performance news entry for the emit path change.

Confidence Score: 5/5

This looks safe to merge.

• No blocking issues found in the changed code.

Important Files Changed

Filename	Overview
reflex/app.py	Updates EventNamespace.emit_update to await socket emits directly and yield once afterward.
news/6734.performance.md	Adds a news fragment describing the emit performance improvement.

_{Reviews (4): Last reviewed commit: "chore: add news fragment for #6734" | Re-trigger Greptile}

[codspeed]

Merging this PR will not alter performance

✅ 26 untouched benchmarks
⏩ 8 skipped benchmarks¹

---

_{Comparing claude/reflex-perf-optimizations-21kg8y-emit-update (24c3f7a) with main (f21eb16)}

Footnotes

1. 8 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[linear-code]

ENG-10110

[masenf]

Independent review: this change cannot reduce concurrency

I dug into this because the create_task wrapper felt load-bearing for concurrency historically — "wrap the emit so it runs independently of other server activity". It wasn't, and here's the evidence, including an explanation of why it genuinely did fix a real bug in 2023.

1. The wrapper never provided concurrency

await asyncio.create_task(coro) means "schedule coro, then suspend me until it finishes". The caller blocks for exactly as long as with await coro; there is no window where caller and emit progress concurrently. Real independence would require not awaiting the task, which the code never did (and shouldn't — update ordering and exception propagation depend on the await). The wrapper's only effects were two extra scheduler hops, a Task allocation, an f-string, and a time.time() call per outgoing update.

2. Nothing about the websocket intake path runs through emit_update

Three layers already decouple intake from emit:

• socketio: async_handlers is left at its default True, so each incoming client event is dispatched into its own task (socketio/async_server.py:609). The engineio reader loop only parses frames and spawns those tasks.
• Reflex: on_event (reflex/app.py:2147) parses and await event_processor.enqueue(...) — a put on an unbounded asyncio.Queue that returns immediately. Handler execution happens in the EventProcessor, one task per event (event_processor.py:597, with per-token FIFO sequencing). emit_update is awaited inside those tasks, so a slow emit can only stall its own event's task, never the reader.
• engineio: sio.emit never touches the network — it ends in queue.put on an unbounded per-connection queue (engineio/async_socket.py:76), and the actual ws.send happens in the dedicated per-connection writer() task (async_socket.py:200). A slow client can't backpressure an event task in either version.

3. Where the wrapper came from, and what it actually fixed

Traced to f9956cd / #1198 (June 2023, "Fix blocking events"): "Fixes the issue of yielding with blocking events by using async tasks to emit socket updates." Back then on_event ran the whole handler chain inline (async for update in process(...)), and the bug was a sync handler doing yield then time.sleep(...) holding interim updates hostage. The comment claiming the task "prevents the update from being blocked behind other coroutines" was added later in 351611c (the rx.background PR), which only moved the pre-existing wrapper into the new emit_update helper.

The subtle part: socketio 5.8 (pinned then) did suspend inside emit (internal create_task + asyncio.wait), so why did a bare await ever fail? Python's pre-3.12 asyncio.wait_for. engineio's writer waits via wait_for(queue.get(), ...), which on ≤3.11 wraps the get in an extra Task, adding a hop to the writer's wake-up chain. With a bare await, the handler resumed one loop slot before the writer reached ws.send, then blocked the loop and the frame sat in the queue. The task wrapper "fixed" it by adding matching extra hops to the caller's resume chain so the writer wins the race. Scheduling-tick arithmetic, never independence — the emit was always fully complete before the caller proceeded.

4. Empirical equivalence across the supported Python range

I ran the real python-socketio/engineio stack (production writer task, fake transport journalling when frames actually hit the wire) through the exact click_yield_interim_value scenario — emit, then block the loop — on 3.10 / 3.11 / 3.12 / 3.14, with both the real socketio emit and a stand-in non-suspending emit (emulating custom client_managers):

Scenario	OLD create_task+await	PR await + sleep(0)	bare await
py ≥ 3.12, real socketio emit	flushed in time	flushed in time	flushed in time
py ≥ 3.12, non-suspending emit	flushed in time	flushed in time	lost
py 3.10/3.11, real socketio emit	flushed in time	flushed in time	lost
py 3.10/3.11, non-suspending emit	lost	lost	lost

The OLD and PR columns are identical in every cell, including the corner where both fail — the strongest available statement of behavior preservation. Two corollaries: the await asyncio.sleep(0) is genuinely load-bearing (this repo supports >=3.10 and integration_app_harness.yml runs 3.11, which is exactly why the first iteration failed test_yield_state_update[click_yield_interim_value]), and a naive "just await it" simplification would have been a real regression.

5. Performance

Benchmarking the real emit path (not a stand-in): old ≈ 60.5 µs/update vs PR ≈ 55 µs/update, matching the delta in the description. Modest, but it's paid while the per-token state lock is held (_execute_event → modify_state_with_links → process_event → chain_updates → emit_delta → emit_update), so same-token event pipelining gets marginally better, not worse. Exception propagation and cancellation outcomes are equivalent — in both versions the inner socketio send-tasks survive caller cancellation, so packet delivery is unchanged.

Minor, non-blocking notes

1. The description's mechanism ("sio.emit can complete without ever suspending") is slightly imprecise for the pinned range — socketio >=5.12 always suspends via internal asyncio.wait; the actual culprit on 3.10/3.11 is the wait_for extra-task hop above. The code comment reads fine either way, since non-suspending emits are real for custom managers.
2. "Cutting scheduling overhead roughly in half" in the news fragment is true of the await-pattern overhead itself, which is ~9% of end-to-end emit cost. Defensible, just worth knowing.
3. The named reflex_emit_event|token|sid|ts task disappears from asyncio task dumps — a small debugging-observability loss, no behavior impact.

Verdict: the change is correct, the retained sleep(0) is the right call, and concurrency is unaffected. 👍

---

Generated by Claude Code