Unable to store ipNetwork cap.

[zenhack]

I'm not 100% sure this is even supposed to be persistent, but there's some disabled code that tries to save the cap to disk and then later restore it. The api.Save() appears to work, as does the restore, but actually using the cap doesn't. not sure what's up.

[zenhack]

Worth noting, if the capability is actually stored, we may also be leaking on every restart.

[paulproteus]

What does "using the cap doesn't" work mean precisely? Does it give you an exception? Do RPCs hang forever with no response?

Perhaps this is a subtler weirder bug than either you or I guessed!

[zenhack]

@paulproteus, testing with commit 0594dc9, which is right before I disabled the restore (because it wasn't working). From the app's perspective it appears to work, but the irc server never even recieves a connection (I tested this by pointing it at a simple tcp server that does a debugging print when accept() returns). Bits just go into the abyss.

Note that this is all being driven by https://github.com/zenhack/go.sandstorm/blob/master/ip/ip.go, which doesn't ever force resolution of the promises. I tried forcing the result of connect() on another branche here: https://github.com/zenhack/go.sandstorm/blob/irc-idler-8-debug/ip/ip.go, but the result is the same.

[zenhack]

To be clear, "forcing" in this context doesn't actaully refer to waiting for a capnp resolve message (go-capnproto2 doesn't do promise resolution yet), and I'm a little fuzzy on exactly what that call to Struct() does in this case, since there's nothing but an interface value to wait for. @zombiezen, what exactly does it do in that case?

[zombiezen]

Struct() will return after the connection receives a Return message for the answer. It has no bearing on a promised capability's resolution. In the code you linked me, you could just as easily use portPromise.Connect(...).Upstream() and have correct results, since you don't need to wait for the struct to do promise pipelining.

Perhaps we need to revisit capnproto/go-capnp#2? I've cleaned up most of the internals of the rpc package now, so I could give it a whirl.

[zenhack]

@zombiezen, properly fixing that issue might make debugging this kind of thing easier, yeah. I doubt that's actually the problem, since both versions of the code work fine with the newly allocated capability, just not the restored version. My hope with the second version was that I'd get an error sooner (or at all), but no such luck.

[zenhack]

I figured this out while adding this to sandstorm-znc; I was just not setting the label param when calling save. There was even a TODO. D'oh.

IRC Idler is officially unmaintained, so I'm not going to bother pushing a fix, but commenting for posterity.