Any way to wait for a Reply to complete?

[rileym-arcules]

Hello!

I'm trying to write a handler where I send a Reply and then need to follow up immediately with a Call within a handler.

My handler looks like so:

func(ctx context.Context, rpcConn *jsonrpc2.Conn, req *jsonrpc2.Request) {
	switch req.Method {
	case "connect":
		// do work
		err := rpcConn.Reply(ctx, req.ID, &result)

		// here, I need to immediately send a request to the same client
		err = rpcConn.Call(ctx, "invite", &params, &next)

	// ...
	}
}

If I try this without the jsonrpc2.AsyncHandler wrapper, the Call call hangs (since it's waiting on the current return I suppose, not really sure why the handler would care about outgoing requests?)

So, I wrap it in the jsonrpc2.AsyncHandler and everything seems to be okay after that. But the problem then is there's a race condition where sometimes the request Call reaches the client before the Reply!

It breaks my matching client code since the result in the Reply returns an identifier as a lookup key that the Call is expecting.

Here's a snippet of the client code that I hope explains it a little better:

// setup Client as the jsonrpc2.AsyncHandler

func (c *Client) Connect(params any) error {
	if err := c.conn.Call(ctx, "connect", params, result); err != nil {
		// handle
	}
	
	c.connected[result.ID] = &foo{}
}

func (c *Client) Handle(ctx context.Context, conn *jsonrpc2.Conn, req *jsonrpc2.Request) {
	switch req.Method {
	case "invite":
		// parse params
		thisFoo, ok := c.connected[params.ID]
		if !ok {
			// sometimes fails here with !ok
		}
	}

[keegancsmith]

Yeah the race makes sense. I think for your use case can't you just put everything after the reply in a new goroutine?

[rileym-arcules]

So to be clear, use the default Sync handler and make the err = rpcConn.Call(ctx, "invite", &params, &next) in a goroutine?

I'm not sure that would truly fix the race, right? In that case I would just be 'delaying' the "invite" call by whatever time it takes to launch the goroutine...

I was thinking it's very odd this is happening since the underlying object stream is an ObjectStream from github.com/sourcegraph/jsonrpc2/websocket . (websockets are ordered by protocol).

[keegancsmith]

@rileym-arcules to be honest we haven't used this library in production in a long time, so all the details of exactly how it works is written in the code rather than being in my mind :) However, the code is not large so hopefully you can find the answer in it or just vendor it in to make it work for your case.