peer #

A peer is another session you can ask a question and get a correlated answer from, so two outstanding questions cannot be confused for each other.

from klbr import peer

session = await peer.open()
handle = await session.send("what does a duplicate skill id do?")
print(handle.request_id)

send returns a request handle, which is also the admission record: the request exists and is durable. It is not an answer and it is not delivery. The answer comes from the handle, and it may not exist yet.

answer = await handle.result(wait_ms=0)

With wait_ms=0 you get whatever is ready. If the peer is still working, yield the turn rather than spin - the request is durable and keyed by request_id, not by your memory:

from klbr import runtime
await runtime.wait(reason="waiting for peer " + handle.peer_id)

New input or the deadline starts a later turn, and the request is still there. On the other side, a peer answers the request it was given, not the one it wishes it had:

await peer.answer(request_id, {"finding": "..."})

The session carries the subject, so nothing repeats peer_id: session.get() reads that peer's standing, session.stop(drain=True) waits for accepted work instead of abandoning it, and handle.cancel() retires a question you no longer need. peer.peers() reads the whole roster.

A re-sent request_id is not a second question: the handle comes back with duplicate=True and nothing new was admitted. That is what makes a retry safe after a turn you are unsure about.

refusals #

A request handle is not a promise of an answer, and nothing times a request out for you. A result is whatever the peer submitted: testimony, not host-verified fact.