fix: dynamically report backend_host in terminal logs

[Krishnachaitanyakc]

Summary

• Fixes notify_backend() which was hardcoding 0.0.0.0 as the backend host in terminal log output, ignoring the backend_host value configured in rxconfig.py or passed via the --backend-host CLI argument.
• Adds an optional host parameter to notify_backend() that falls back to config.backend_host when not provided.
• Passes the resolved host from run_backend() and run_backend_prod() call sites so CLI --backend-host overrides are correctly reflected in logs.
• Persists the resolved backend_host in the config (via _set_persistent) so it is available to notify_backend() even when called from the frontend thread in run_process_and_launch_url().

Closes #6165

Test plan

• Run reflex run with default config and verify log shows the correct default backend host
• Set backend_host="127.0.0.1" in rxconfig.py, run the app, and verify the log shows http://127.0.0.1:<port> instead of http://0.0.0.0:<port>
• Run with --backend-host 192.168.1.1 CLI flag and verify the log shows the CLI-specified host
• Run in production mode (reflex run --env prod) with a custom backend_host and verify the log is correct

[greptile-apps]

Greptile Summary

This PR fixes a long-standing cosmetic bug where notify_backend() always displayed 0.0.0.0 as the backend host in terminal log output, regardless of backend_host set in rxconfig.py or via --backend-host. The fix is small, focused, and follows the existing port-persistence pattern already present in reflex.py.

Changes:

• notify_backend() now accepts an optional host parameter that falls back to config.backend_host when not supplied.
• run_backend() and run_backend_prod() now explicitly pass their host argument to notify_backend().
• reflex.py persists the resolved backend_host into the config (mirroring how frontend_port/backend_port are already persisted), so that notify_backend() in run_process_and_launch_url (which is run from a separate frontend thread) can still read the correct value via get_config().

Issues found:

• effective_host = host or config.backend_host uses Python's truthiness check rather than an explicit is not None guard. An empty-string host would silently fall back to the config value. Prefer host if host is not None else config.backend_host.
• The notify_backend() call inside run_process_and_launch_url (line 233) is intentionally left without a host argument — it relies on the config having been updated via _set_persistent earlier. This works but could be fragile; a brief comment explaining the intent would improve maintainability.

Confidence Score: 4/5

• Safe to merge after addressing the or vs is not None guard and optionally adding a comment at the implicit call site.
• The core logic is correct and mirrors existing patterns in the codebase. The or vs is not None issue is unlikely to cause a real-world problem (no caller passes an empty-string host), but it is a style divergence from the project convention. No correctness, security, or data-loss concerns.
• reflex/utils/exec.py — the or guard on line 167 and the implicit-host call on line 233.

Important Files Changed

Filename	Overview
reflex/utils/exec.py	Adds optional host parameter to notify_backend() and passes the resolved host from run_backend and run_backend_prod. The run_process_and_launch_url call site (line 233) still omits the host arg, relying on config persistence. Minor: uses or instead of is not None for the None-check on host.
reflex/reflex.py	Persists the resolved backend_host into the config via _set_persistent when it differs from the existing config value, mirroring the existing pattern already used for frontend_port and backend_port.

Sequence Diagram

sequenceDiagram
    participant CLI as CLI / rxconfig
    participant _run as _run() [reflex.py]
    participant Config as Config [_set_persistent]
    participant BackendThread as Backend Thread
    participant FrontendThread as Frontend Thread
    participant notify as notify_backend()

    CLI->>_run: backend_host (CLI arg or config default)
    _run->>Config: _set_persistent(backend_host) [if changed]
    _run->>_run: get_config(reload=True)

    _run->>BackendThread: run_backend(host, port, ...)
    BackendThread->>notify: notify_backend(host) ✅ explicit host

    _run->>FrontendThread: run_process_and_launch_url(...)
    FrontendThread->>notify: notify_backend() [no host arg]
    notify->>Config: get_config().backend_host [reads persisted value]
    notify-->>FrontendThread: logs correct host ✅

Loading

Comments Outside Diff (1)

1. reflex/utils/exec.py, line 232-233 (link)

   notify_backend() still called without explicit host in run_process_and_launch_url

   This call site is left without a host argument, relying instead on the _set_persistent + get_config(reload=True) path taken earlier in _run() to have baked the resolved host into the reloaded config. The fix works for the common code path, but it creates a subtle distance between the "source of truth" (the persistent config env-var) and this display call.

   A more explicit and resilient approach would be to thread the resolved backend_host into run_process_and_launch_url (or at least read it from the config explicitly before calling), so that future refactors don't silently regress this behaviour if the persistence order ever changes.

   Consider adding a brief inline comment here explaining why no host is passed:

   _{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

_{Reviews (1): Last reviewed commit: "fix: use configured backend_host in noti..." | Re-trigger Greptile}

[codspeed-hq]

Merging this PR will not alter performance

✅ 8 untouched benchmarks

---

_{Comparing Krishnachaitanyakc:fix/notify-backend-host-6165 (0540c69) with main (1e78f2c)}