This change fixes a bug that causes PlainObjectCodec to
lose additional messages from stream. json.Decoder has
an internal buffer that reads more than one message, but
is discarded after every use. Now PlainObjectCodec reuses
encoder and decoder within a buffered stream, however
using it directly in your code retains the old, incorrect
behaviour.
A user should now use plainObjectStream if he needs
plain JSON-RPC 2.0 stream without headers.
`NewPlainObjectStream` method has been added for this reason.
Before this commit, a custom logger could be set with the LogMessages
function. However, by using LogMessages not only is a custom logger set
but also all received and sent messages are logged. Use cases exist
where a custom logger is desired to log errors but not all messages.
This change makes the treatment of params and meta the same, by
assigning a well-known pointer at first to detect if the unmarshaling
process overwrites it with an explicit nil, or it stays the same in
which it means that it was unset from the beginning.
Before, the Call method dispatched the JSON-RPC request and waited
until completion of the request before returning. This made it difficult
to release any locks that need to be released upon dispatch.
Now, the Call method is broken into a DispatchCall and Wait pair.
DispatchCall returns a proxy to the internal call object as soon as the
request is dispatched. When appropriate, the caller can invoke the Wait
method on this proxy to block until the result is ready.
The original Call method is not changed, but now implemented by
these primitives.
The 'result' key MUST be unset according when the error key is set.
This is not what is happening right now. When the error is set,
"result":null is returned in the response payload. This patch is fixing
the issue by adding omitempty for the result field.
NOTE: This is a breaking change to the expected contract of Handler. Please update your implementation to use AsyncHandler if needs be.
We have strict ordering requirements of how we handle FileSystem requests in
LSP. As such relying on the ordering the goroutine scheduler runs requests in
leads to potential out of order mutations to the FS. As such we update the
jsonrpc2 implementation to by default block until Handle returns (note it can
still respond to the request at a later stage). For more simple use cases we
provide the AsyncHandler which will work like the previous implementation.
* Ensure handle is blocking
Running various applications that use jsonrpc2 with the Go race detector shows that there is a race condition where `WriteObject` can be called from concurrent goroutines (e.g., 1 sending a request, 1 writing a response).
This makes the MarshalJSON/UnmarshalJSON methods centralize the logic, instead of requiring callers to occasionally munge responses to make them valid to later JSON-marshal.
Previously, we incorrectly interpreted these as neither a request nor a response, and we printed an error for them. This is incorrect behavior per JSON-RPC 2.0 spec; responses can have a null result.
