Trait ClientDispatch 

pub trait ClientDispatch {
    // Required methods
    fn call_raw(
        &mut self,
        service_entity: &str,
        request_cdr: &[u8],
        response_buf: &mut [u8],
    ) -> NodeResult<usize>;
    fn send_goal_raw(
        &mut self,
        action_entity: &str,
        goal_cdr: &[u8],
    ) -> NodeResult<GoalId>;

    // Provided methods
    fn service_is_ready(&self, service_entity: &str) -> NodeResult<bool> { ... }
    fn action_server_is_ready(&self, action_entity: &str) -> NodeResult<bool> { ... }
}

Executor-backed CLIENT operations a TickCtx drives (Phase 212.M-F.4).

Service-client call + action-client send_goal need &mut Executor (the W.5.6 client handles live on the executor), which a mid-spin callback can’t hold. They run from ExecutableNode::tick, between spins. The generated runtime impls this over the real executor + the service/action client handles (resolved by stable client entity id); the component never sees the executor directly. Kept as a trait so TickCtx stays no_std + free of the rmw-cffi-gated Executor type.

Mirrors the sibling ActionExecutor (server-side ops). Splitting client vs server keeps each trait small + lets the codegen-side GenClientDispatch impl resolve client handles independently from server handles.

Required Methods

fn call_raw( &mut self, service_entity: &str, request_cdr: &[u8], response_buf: &mut [u8], ) -> NodeResult<usize>

Issue a service-client request on service_entity carrying CDR request_cdr; block on the reply, write the response CDR into response_buf, return the response length in bytes.

The synchronous block is built on the executor-driven send_request_raw + take_response_raw pair (phase-301: the RMW layer has no blocking call) — the tick hook drives the executor between callback dispatch, so a blocked call_raw does not starve other callbacks (each tick yields back to the runtime after returning).

fn send_goal_raw( &mut self, action_entity: &str, goal_cdr: &[u8], ) -> NodeResult<GoalId>

Send an action-client goal request on action_entity carrying CDR goal_cdr; return the assigned GoalId (server-stamped on the goal-accept response). Result + feedback streams arrive via callback dispatch — not this method.

Provided Methods

fn service_is_ready(&self, service_entity: &str) -> NodeResult<bool>

Whether a server for the service client service_entity is CURRENTLY discoverable — rclcpp::ClientBase::service_is_ready, for a tick.

phase-428 W13. Three answers: Ok(true), Ok(false), or Err when the backend cannot say (no discovery channel, or the entity is unknown). A tick that gates its first call_raw on Ok(true) and treats Err as “call anyway” keeps the request-is-the-probe behaviour on backends without discovery and stops sending into the void on the ones with it.

Default Err(NodeDeclError::Runtime) — “cannot say” — so an implementor that predates this method (the orchestration codegen’s dispatch) keeps its shape.

fn action_server_is_ready(&self, action_entity: &str) -> NodeResult<bool>

Whether a server for the action client action_entity is CURRENTLY discoverable — rclcpp_action::Client::action_server_is_ready, for a tick. Same three answers as Self::service_is_ready, read off the action’s send_goal service (issue 1918): a goal sent before the server has declared it is answered by nobody, and the declarative client sends ONCE.

Dyn Compatibility

This trait is dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety".

Implementors