Recent changes introduced to JSONRPCProtocol (and other classes that allow the user to provide a custom ID generator) introduced a situation where multiple JSONRPCProtocol instances constructed with default arguments (i.e. no explicitly provided ID generator) share the same global ID generator. As a consequence, unit tests employing an unparameterized JSONRPCProtocol instance in downstream projects may no longer assume that the IDs of a JSONRPCProtocol instance start from 1. Furthermore, this leads to unpredictable results if unit tests are run in parallel.
The solution would be to change the constructor of JSONRPCProtocol (and other protocol classes using the same solution) as follows:
Recent changes introduced to
JSONRPCProtocol
(and other classes that allow the user to provide a custom ID generator) introduced a situation where multipleJSONRPCProtocol
instances constructed with default arguments (i.e. no explicitly provided ID generator) share the same global ID generator. As a consequence, unit tests employing an unparameterizedJSONRPCProtocol
instance in downstream projects may no longer assume that the IDs of aJSONRPCProtocol
instance start from 1. Furthermore, this leads to unpredictable results if unit tests are run in parallel.The solution would be to change the constructor of
JSONRPCProtocol
(and other protocol classes using the same solution) as follows:This creates a per-instance ID generator so separately constructed
JSONRPCProtocol
instances no longer have a dependency between them.