Skip to content

fix: dynamically report backend_host in terminal logs#6222

Open
Krishnachaitanyakc wants to merge 1 commit intoreflex-dev:mainfrom
Krishnachaitanyakc:fix/notify-backend-host-6165
Open

fix: dynamically report backend_host in terminal logs#6222
Krishnachaitanyakc wants to merge 1 commit intoreflex-dev:mainfrom
Krishnachaitanyakc:fix/notify-backend-host-6165

Conversation

@Krishnachaitanyakc
Copy link

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

…oded 0.0.0.0

The notify_backend() function was hardcoding "0.0.0.0" as the backend
host in the terminal log output, ignoring the backend_host value set in
rxconfig.py or passed via --backend-host CLI argument.

This change:
- 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 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()

Fixes reflex-dev#6165
@greptile-apps
Copy link
Contributor

greptile-apps bot commented Mar 25, 2026

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)

    P2 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

host: The backend host. If not provided, falls back to the config value.
"""
config = get_config()
effective_host = host or config.backend_host
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Use is not None instead of or for optional host

host or config.backend_host will silently discard an explicit empty string "" passed as host, falling back to the config value instead. Per project convention, you should check is not None to differentiate between "not supplied" and "explicitly empty":

Suggested change
effective_host = host or config.backend_host
effective_host = host if host is not None else config.backend_host

Rule Used: When checking for the existence of a value that co... (source)

Learnt From
reflex-dev/flexgen#2444

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

exec.py: notify_backend() hardcodes 0.0.0.0, backend_host config shows invalid IP in logs

1 participant