Concurrent client submits are tracked in ARCPClient._pending_accepts as a deque, and _on_job_accepted at src/arcp/_client/dispatch.py:91 resolves the next pending future with popleft() regardless of which submit request the accepted job belongs to. JobAcceptedPayload does not carry a request id, and the runtime creates a new envelope id for job.accepted, so the client has no request-level correlation. The in-tree runtime currently serializes submit handling enough to hide this in common cases, but a peer that accepts jobs out of order or a future runtime path that performs asynchronous credential issuance differently can resolve submit calls with the wrong job_id, lease, agent, or trace metadata.
Fix prompt: Add explicit request correlation for job acceptance. The smallest protocol-compatible approach is to include the submit envelope id as a request_id field in job.accepted payloads and have the client use the existing pending registry instead of a FIFO deque; if the wire contract cannot change, document and enforce in-order acceptance at the transport/protocol boundary. Add a test transport or fake peer that returns two job.accepted envelopes in reverse order and assert that two concurrent client.submit calls receive their own accepted payloads.
Concurrent client submits are tracked in
ARCPClient._pending_acceptsas a deque, and_on_job_acceptedatsrc/arcp/_client/dispatch.py:91resolves the next pending future withpopleft()regardless of which submit request the accepted job belongs to.JobAcceptedPayloaddoes not carry a request id, and the runtime creates a new envelope id forjob.accepted, so the client has no request-level correlation. The in-tree runtime currently serializes submit handling enough to hide this in common cases, but a peer that accepts jobs out of order or a future runtime path that performs asynchronous credential issuance differently can resolve submit calls with the wrongjob_id, lease, agent, or trace metadata.Fix prompt: Add explicit request correlation for job acceptance. The smallest protocol-compatible approach is to include the submit envelope id as a
request_idfield injob.acceptedpayloads and have the client use the existing pending registry instead of a FIFO deque; if the wire contract cannot change, document and enforce in-order acceptance at the transport/protocol boundary. Add a test transport or fake peer that returns twojob.acceptedenvelopes in reverse order and assert that two concurrentclient.submitcalls receive their own accepted payloads.