Skip to main content

RequestErrorNotifier

mbus_client::app

Trait RequestErrorNotifier 

Source 
pub trait RequestErrorNotifier {
    // Required method
    fn request_failed(
        &mut self,
        txn_id: u16,
        unit_id_slave_addr: UnitIdOrSlaveAddr,
        error: MbusError,
    );
}
Expand description

Trait for receiving notifications about failed Modbus requests.

This is used to handle timeouts, connection issues, or Modbus exception responses at the application level, allowing the implementor to gracefully recover or alert the user.

Required Methods§

Source

fn request_failed( &mut self, txn_id: u16, unit_id_slave_addr: UnitIdOrSlaveAddr, error: MbusError, )

Called by the client stack whenever a previously queued request cannot be completed.

The error parameter identifies the exact failure cause. The following variants are delivered by the stack’s internal poll() and handle_timeouts() logic:

  • MbusError::ModbusException(code) — The remote device replied with a Modbus exception frame (function code 0x80 + FC). The server understood the request but refused to execute it (e.g. illegal data address, illegal function). Delivered immediately inside the poll() call that received the exception response, before any retry logic runs.

  • MbusError::NoRetriesLeft — The response timeout expired and every configured retry attempt was exhausted. handle_timeouts() waits response_timeout_ms milliseconds after each send, schedules each retry according to the configured BackoffStrategy and JitterStrategy, and fires this error only after the last retry attempt has itself timed out without a response. The request is permanently removed from the queue.

  • MbusError::SendFailed — A scheduled retry was due (its backoff timestamp was reached inside handle_timeouts()), but the call to transport.send() returned an error (e.g. the TCP connection or serial port was lost between the original send and the retry). The request is dropped immediately; remaining retries in the budget are not consumed.

§Notes
  • Each call corresponds to exactly one transaction. After this call the request is permanently removed from the internal expected-response queue and will not be retried again. No further callbacks will be issued for the same txn_id.
  • The txn_id is always the value supplied when the request was originally enqueued, even for Serial transports that do not transmit a transaction ID on the wire.
§Parameters
  • txn_id: Transaction ID of the original request.
  • unit_id_slave_addr: The target Modbus unit ID (TCP) or slave address (Serial).
  • error: The specific MbusError variant describing the failure (see above).

Implementors§