Ian Denhardt

Prompted by 9ee620ebdb08e224f5b109e048e1bc01d6639a89, in which I just happened to stumble across a possible integer overflow. We should come up with some more systematic/robust way of writing this kind of code...

The implementation does *not* panic, and in fact some of the tests depend on this behavior to do a defer client.Release() even though they may end up releasing a client...

Presumably at some point this code was in a method called Resolve, but this should be Fulfill now.

Fix #306

2

Also, document the fact that ClientPromise.Fulfill steals the reference. Mixing this up was the root cause of the issue. Specifically both Promise.ReleaseClients() and Message.Reset() were releasing the same clients, causing...

This only ever has length 1, so let's just use a pointer. I would hazard a guess this is a holdover from the logic for .Join() that was removed.

Documentation added in #308 makes this redundant; the ReleaseFuncs returned by the transport already releases any caps in the message, and in all cases this was called immediately before releasing...

While picking through the code trying to solve #306, I discovered a few bits of the API that were not adequately documented, so I fixed the docs. See individual commits.

Presumably at some point this was renamed.

When attempting to upload a large directory with ocap-merkledag, I see an imported capability being released, and then subsequently passed to another call, resulting an exception due to the invalid...

A substantial amount of the complexity of the transport package is due the interface: we pass contexts to functions that do IO, and then jump through hoops to respect those...