Requesting `drive.version` for the same URL multiple times in one session hangs

[josephmturner]

Good news!! Requests sent to hyper-sdk-rpc successfully roundtripped back to Emacs!! ;D

It looks like when we send two requests in a single session to check a drive's version, it hangs the second time. For example:

{"jsonrpc":"2.0","id":3,"method":"sdk.getDrive(url).version","params":{"url":"test"}}

works the first time. After a successful response, we can then send further successful requests to check the version of other URLs. But if we send the same request again even if other requests have been made in the interim, the rpc server hangs. This issue also happens when we attempt to check the version of an existing drive twice as in:

{"jsonrpc":"2.0","id":4,"method":"sdk.getDrive(url).version","params":{"url":"hyper://blog.mauve.moe"}}

We attempted sending multiple requests in rapid succession before waiting for the responses, and hyper-sdk-rpc handled these just fine so long as the same URL was not requested twice.

EDIT: The version numbers are different on subsequent requests. I had copied the same request twice accidentally.

[RangerMauve]

Test to add:

• init fake sdk with property getter
• make client-server wrapper
• invoke get on the property
• try same invocation
• test that both resolve

[josephmturner]

I added a test in #10 that uses a shim sdk. It passes.

Here's how I reproduce this issue on my machine:

This is the request that jsonrpc.el sends to hyper-sdk-rpc:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "sdk.getDrive(url).version",
  "params": {
    "url": "test"
  }
}

hyper-sdk-rpc responds immediately:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": 1
}

If I then send

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "sdk.getDrive(url).version",
  "params": {
    "url": "test"
  }
}

then hyper-sdk-rpc hangs.

[josephmturner]

Please take a look at the updated #10, which now test against the real hyper-sdk. The second test hangs.

[RangerMauve]

Tested this more with adam, the issue was that blog.mauve.moe was having trouble resolving not that the version accessor was busted.