`CapDescriptor.receiverAnswer` not handled (or emitted where appropriate)
zenhack opened this issue · comments
Today I discovered that the rpc subsystem does not handle incoming capabilities whose variant is set to receiverAnswer. This means that, depending on the implementation of the remote vat, attempts to do things like (pseudocode):
cap.Bar(cap.Foo().Cap)
...may unnecessarily result in errors. i.e. if you try to pass a capability from the result of a not-yet-returned call to another method, the Go implementation will just reject it outright.
This does not currently break go-to-go communication since the go implementation also does not emit these; instead, it just sends them as senderHosted and hides the fact that they actually live in the receiving vat. This is a hack, but it works for basic cases.
This is likely to cause compatibility problems with other implementations, and I'm frankly a bit surprised we haven't hit it already, though I suppose I might well be the only one who's even tried to use v3 to talk to non-go servers, and could have just gotten lucky so far.
This is also bad because it means that calls the reciever makes on its argument will uselessly round-trip through the remote vat, even though in principle we should know that it will resolve to an object in the local vat.
This also limits functionality, since it means in code such as the above, it is not possible for cap to discover that its argument lives locally; I'm working on an application where I need exactly this. So I will likely try to address this soonish.
This is related to but not exactly the same as what we do with senderPromise vs. senderHosted -- that will cause a similar limitation when using NewPromiseClient. But this version affects simple pipelining.
I fixed this a while ago, closing.