The backend_trace.py module#

Summary#

trace_call

Log a single backend_call entry when tracing is enabled.

Description#

Diagnostic tracer for backend state-query calls.

Enable with the FLUIDS_BACKEND_TRACE env var:

  • 1 / true / on — emit one INFO line per call, no stack.

  • stack — INFO line plus a 6-frame caller stack (skipping this module + backend wrappers).

Disabled by default — zero cost when the env var is unset.

The point of this tracer is to answer the operational question “who is hitting the live Fluent session when there is no user query in flight?” without having to attach a debugger. Every get_state / get_active_status / get_named_object_names / solver_status / run_code entry logs a single backend_call event tagged with method name, arg shape, and (optionally) the calling frame. Filter the agent log on backend_call and you can immediately see whether the chatter is coming from our own code (validator, preface, MCP tool, …) or from PyFluent’s internal heartbeat (which will not appear here because PyFluent’s RPCs do not flow through our wrappers).

Module detail#

backend_trace.trace_call(method: str, *, summary: str = '') None#

Log a single backend_call entry when tracing is enabled.

method is the canonical backend method (get_state, get_active_status, …). summary is an optional short string describing arg shape (e.g. "paths=4"). Never raises.

Parameters:
methodstr

Backend method name being traced.

summarystr

Short description attached to the trace entry.

Returns:
None

The function completes through its side effects.