Struct AppServerTransport 

pub struct AppServerTransport {
    outbound_tx: Sender<Outbound>,
    incoming_rx: Mutex<Receiver<AppServerIncoming>>,
    reader_task: Mutex<Option<JoinHandle<()>>>,
    shared: Arc<SharedState>,
    next_request_id: AtomicU64,
    initialize_state: AtomicU8,
    max_frame_bytes: usize,
    max_pending_requests: usize,
}

Fields

outbound_tx: Sender<Outbound>

incoming_rx: Mutex<Receiver<AppServerIncoming>>

reader_task: Mutex<Option<JoinHandle<()>>>

shared: Arc<SharedState>

next_request_id: AtomicU64

initialize_state: AtomicU8

max_frame_bytes: usize

max_pending_requests: usize

Implementations

impl AppServerTransport

pub fn new<R, W>(reader: R, writer: W, limits: AppServerLimits) -> Self

where R: AsyncRead + Unpin + Send + 'static, W: AsyncWrite + Unpin + Send + 'static,

pub fn is_initialized(&self) -> bool

pub fn failure(&self) -> Option<AppServerError>

pub async fn next_incoming(&self) -> Option<AppServerIncoming>

async fn wait_for_reader_to_finish(&self)

Wait for run_reader to finish processing whatever was already buffered on stdout. The reader terminates on its own shortly after the child’s stdout pipe closes (EOF on process exit), but a caller classifying the exit right after Child::wait() returns can race ahead of it: child.wait() only reports the OS-level exit, not whether the reader has finished parsing the final bytes. Without this, a malformed/oversized final frame can be misclassified as UnexpectedEof/NonZero/BeforeInitialize instead of ProtocolViolation, because self.failure() hadn’t been set yet.

pub async fn request( &self, method: &str, params: Value, request_timeout: Duration, ) -> Result<Value, AppServerError>

pub async fn notify( &self, method: &str, params: Value, write_timeout: Duration, ) -> Result<(), AppServerError>

pub async fn respond_tracked( &self, id: RpcId, result: Result<Value, ServerResponseError>, write_timeout: Duration, outcome: &WriteOutcomeTracker, ) -> Result<(), AppServerError>

Same as respond, but also reports via outcome whether it would be safe to retry after a non-success result — including a caller whose own future is cancelled while this is still awaiting the write-confirmation ack, which never produces a return value at all (see WriteOutcomeTracker, write_value_tracked). A caller that mistakes “timed out/cancelled waiting for confirmation” for “never sent” and retries risks a second, duplicate response for the same id (ReAgent P1, PR #3212 6th review).

pub async fn initialize( &self, timeout: Duration, ) -> Result<Value, AppServerError>

pub async fn shutdown(&self, timeout: Duration) -> Result<(), AppServerError>

async fn write_value(&self, value: Value) -> Result<(), AppServerError>

async fn write_value_tracked( &self, value: Value, outcome: &WriteOutcomeTracker, ) -> Result<(), AppServerError>

See WriteOutcomeTracker. outcome moves to OUTCOME_UNCONFIRMED the instant the frame is handed to run_writer — before awaiting its write-confirmation ack — and to CONFIRMED_UNDELIVERED if that ack later reports a genuine failure, rather than staying stuck at “unconfirmed” forever for an outcome that in fact became known.