# 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.

```python
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.

```python
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:

```python
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:

```python
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.