Struct InFlight 

pub struct InFlight { /* private fields */ }

A command that has been handed to the loop and not yet answered.

Issue order is write order, and neither is completion order. The loop dequeues commands FIFO and writes them in that order, so a command issued first reaches the JVM first. Nothing says the JVM answers in that order — JDWP’s own words are that the protocol “is asynchronous; multiple command packets may be sent before the first reply packet is received”, matched by an id that “must be unique among all outstanding commands sent from one source”. So this type carries its id: correlation is the claim being made, and ADR-0038 asserts it rather than assuming it.

Dropping one is safe, and that is a property of ADR-0018 rather than of this type. Abandoning the wait does not abandon the command: the JVM still answers it, the reader task still consumes the whole packet, and route_reply finds the pending entry and discards the reply because nobody is listening. Framing cannot be lost that way, because framing does not live on this side of the channel. What dropping does cost is the work the JVM already did, which is why nothing here abandons a sibling on the strength of another’s failure — see JdwpConnection::read_independently.

Implementations

impl InFlight

pub const fn id(&self) -> u32

The packet id this command was sent with, and the id its reply must carry.

pub async fn reply(self) -> JdwpResult<ReplyPacket>

Wait for this command’s reply.

Errors

Returns a JdwpError if the reply is lost before it arrives — a write failure, a lapsed REPLY_TIMEOUT, or the loop shutting down — naming the reason the loop stopped when it recorded one.