Fix nested request reply service feedback

Author: hhenson

AGENTS.md

@@ -64,7 +64,7 @@ uv build --wheel --python 3.12 --out-dir "$wheel_dir"
 uv venv --python 3.14 "$test_env"
 uv pip install --python "$test_env/bin/python" \
   "$wheel_dir"/*.whl "pytest>=8" "frozendict>=2.4" "tornado>=6.5" \
-  trove-classifiers
+  "polars>=1.32" trove-classifiers
 "$test_env/bin/python" -m pytest python/tests -q -m "not wip"
 ```
 
@@ -75,6 +75,19 @@ local Linux VM before reporting completion. Use the Ubuntu/OrbStack workflow in
 safety is involved. macOS is the normal local gate. Windows remains a
 best-effort CI platform, but portable code should still be maintained.
 
+The x86_64 OrbStack VM on Apple Silicon does not expose AVX/AVX2. Standard
+Polars warns about the missing CPU features and then segfaults inside
+`_polars_runtime` during ordinary `DataFrame` construction. This is a VM
+dependency issue, not an hgraph failure. Always install the compatibility
+runtime before running the Python suite in that VM:
+
+```sh
+uv pip install --python "$test_env/bin/python" "polars[rtcompat]>=1.32"
+```
+
+Do not retry the full suite with standard Polars after seeing its missing-CPU-
+features warning; switch to `rtcompat` immediately.
+
 GitHub CI runs after a push and is not a substitute for these local gates. The
 user monitors post-push CI and will report platform-specific failures. Do not
 wait for or monitor CI unless asked.

docs/source/developer_guide/architecture.rst

@@ -172,7 +172,7 @@ exceptions exist, each declared rather than accidental:
   scheduled then splits by kind — the boundary scheduling matrix:
 
   - **Shared-output relays** (adaptor ``from_graph``/``to_graph``, reference
-    service outputs, service response outputs, context/shared outputs) are
+    and subscription service outputs, context/shared outputs) are
     **rank-correct and same-cycle**: pairs are declared with
     ``Wiring::add_same_cycle_pair``, which rank-constrains the paired source
     *after* every capture; ``Wiring::finish`` re-ranks the whole graph once
@@ -187,9 +187,12 @@ exceptions exist, each declared rather than accidental:
     sanctioned **next-cycle** forwarders: the pairing is rank-free (no rank
     dependency at all), and the capture forwards to the service source at
     ``evaluation_time + MIN_TD`` (current time during ``start``). The temporal
-    break — not a wiring edge — is what allows a client's request to derive
-    from the service's own response without creating a wiring cycle, exactly
-    like ``feedback``.
+    break ensures client mutations never run the implementation in the same
+    engine cycle. Request/reply responses additionally pass through an explicit
+    outer-graph ``feedback`` edge before their shared response source is
+    published. Request/reply clients are therefore excluded from indirect
+    service ranking, permitting recursive and mutually dependent request/reply
+    calls without making this a property of nested-graph consumers.
 
 Anything else pointing backward is a wiring bug.
 

docs/source/developer_guide/parity_matrix.rst

@@ -303,13 +303,13 @@ model.
        request/reply services, and late subscription to an existing value all
        execute through the erased C++ service runtime. Matching public C++
        tests cover constrained generics, erased specialization identity,
-       reply-less requests, and sampled late subscriptions. Request/reply
-       forwarding deliberately uses one request cycle followed by same-cycle
-       reply publication, so it is one cycle faster than the old Python
-       executor. Calling a service from inside a compiled ``map_`` or ``mesh_``
-       child still requires a cross-child service endpoint import and remains
-       a nested-boundary task; private Python service-builder layouts are not
-       compatibility targets.
+       reply-less requests, and sampled late subscriptions. Request/reply uses
+       the Python timing model: request capture advances one cycle and reply
+       publication crosses an outer-graph feedback edge before the client sees
+       it. Compiled ``map_`` and ``mesh_`` children import their outer service
+       transport inputs through the nested boundary; request/reply feedback is
+       owned by the outer implementation, not by the child consumer. Private
+       Python service-builder layouts are not compatibility targets.
 
 The 215 upstream ``ts_tests`` tests were also copied mechanically to a
 temporary directory and run against the current bridge under Python 3.12.8.
@@ -529,8 +529,8 @@ Wiring and node-authoring surface
      - Full at a graph boundary
      - Path-aware and generic multi-interface implementations, template and
        erased descriptors, multiple request arguments, reply-less requests,
-       and reference-counted subscriptions. Service calls inside compiled
-       keyed children remain the nested-boundary exception described above.
+       reference-counted subscriptions, Python-compatible request/reply
+       feedback, and service calls inside compiled keyed children.
    * - ``@adaptor`` / service adaptors
      - Full (core and supported families)
      - Source/sink/duplex and per-client keyed service-adaptor exchange are

docs/source/developer_guide/roadmap.rst

@@ -554,12 +554,6 @@ The following are intentional unless separately re-opened:
   TSS/TSD delta that nets to no change does not tick. Explicit writes are
   unaffected and match upstream exactly: a python node returning the same
   scalar each evaluation ticks each time, as do repeated TSD entry writes.
-- **Lower-latency request/reply** (ruling 2026-07-18): a request/reply
-  service round-trip completes in one fewer engine cycle than upstream — the
-  reply is observable at the requester one cycle earlier (hg_cpp yields
-  ``[None, value]`` where upstream yields ``[None, None, value]``). This is a
-  deliberate latency improvement, not a defect; upstream tests that pin the
-  exact cycle count therefore see the reply one index earlier.
 - Python ``REF`` is an opaque value and does not expose ``.output``.
 - ``None`` in CompoundScalar/Bundle construction means an unset field.
 - TSB deltas are canonically dense; sparse-bundle delta parity is not required.

docs/source/developer_guide/services.rst

@@ -53,7 +53,7 @@ source/capture pair** — applied with different payloads:
 - **Scheduling matrix** (see *Lifecycle Teardown* in :doc:`architecture` for
   the invariant statement):
 
-  - **Shared-output relays** (reference outputs, service responses, adaptor
+  - **Shared-output relays** (reference and subscription outputs, adaptor
     ``from_graph``/``to_graph``, contexts) are **rank-correct and
     same-cycle**: pairs are declared with ``Wiring::add_same_cycle_pair``
     (source rank-constrained after every capture); ``Wiring::finish`` re-ranks
@@ -66,8 +66,12 @@ source/capture pair** — applied with different payloads:
     **next cycle** by design: the pairing is rank-free (no rank dependency),
     and the capture schedules the service source for
     ``evaluation_time + MIN_TD`` (current time during ``start``). The temporal
-    break replaces a wiring edge, so a client's request may derive from the
-    service's own response — the same one-cycle rule as ``feedback``.
+    request mutation does not run the implementation in the capture cycle.
+  - **Request/reply responses** cross an explicit feedback source/sink pair in
+    the graph that owns the implementation, then publish through the ordinary
+    same-cycle shared-output relay. Request/reply clients are omitted from
+    indirect service ranking, so recursive request/reply calls are legal. No
+    nested client or higher-order operator constructs this feedback path.
 - **Lifecycle:** the source clears its captured state on ``stop``. A restarted
   graph must republish through capture before the source can produce a live
   shared output.
@@ -107,7 +111,10 @@ The per-flavour payloads:
   before the source emits, so the final request delta is **cumulative**
   (``make_request_input_source_node`` / ``make_request_input_capture_node``;
   proven by "request/reply source emits cumulative client requests" in
-  ``test_service_wiring.cpp``).
+  ``test_service_wiring.cpp``). The implementation output is captured by an
+  outer-graph feedback sink and replayed on the following cycle before the
+  keyed shared response is published. A direct request therefore has Python's
+  observable sequence ``[None, None, response]``.
 
 Related decision recorded with this layer: real-time wall-clock scheduler
 alarms use the normal graph schedule queue — ``NodeScheduler(...,
@@ -467,9 +474,9 @@ second implementation for the same service kind + path throws
 **Semantics proven by tests** (``test_service_wiring.cpp``): a reference client
 reads the implementation output by reference (no copy); paths keep shared
 outputs separate; a subscription client's keys reach the implementation on the
-next cycle and the response flows back keyed; request/reply replies are keyed
-by the client's request id; two clients' requests reach the implementation as
-one cumulative delta.
+next cycle and the response flows back keyed; request/reply replies cross the
+outer feedback edge and remain keyed by the client's request id; two clients'
+requests reach the implementation as one cumulative delta.
 
 
 How a client expression lowers

docs/source/user_guide/authoring_graphs_cpp.rst

@@ -853,7 +853,7 @@ verb**. How the flavours (and the adaptor kinds of the next section) differ:
    * - **Request/reply service**
      - ``request_schema`` + ``response_schema``
      - ``wire<S>(w, request)``
-     - its **own** reply (next cycle)
+     - its **own** reply (after request and response cycle boundaries)
      - ``TSD<Int, request_schema>`` keyed by client id in; ``TSD<Int, response_schema>`` keyed by the same id out
    * - **Adaptor**
      - ``: adaptor::interface`` + ``input_schema`` / ``output_schema``
@@ -1010,13 +1010,16 @@ so its reply is erased:
        static Port<TS<Int>> compose(Wiring &w, Port<TS<Int>> request)
        {
            service::register_request_reply_service<AddOneService, AddOneImplNode>(w);
-           return wire<AddOneService>(w, request);      // this client's own reply, next cycle
+           return wire<AddOneService>(w, request);      // this client's own delayed reply
        }
    };
 
 Two clients of the same service are two independent request-dictionary
 entries; the implementation sees both requests in one cumulative delta and
-each client receives only its own reply.
+each client receives only its own reply. Request capture advances one engine
+cycle and response publication crosses a second, outer-graph feedback edge;
+the observable sequence for one request is therefore
+``[None, None, response]``, matching Python.
 
 Paths and other service mechanics
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~