This addresses two items:
- Use ApplicationError instead of InvalidRequest for custom
application errors. Avoiding confusing regarding the usage of
InvalidRequest (although the actual error code used could/would
be different).
- Allow for defining an optional data object that gets returned
in the error response, as per json-rpc specification.
HTTP has a 128 MB limit, while websock uses the library default (20 MB).
Align both to 128 MB. This should be enough for an Ethereum `getPayload`
with 6 blobs, all hex encoded binary + JSON overhead.
In #195, a regression got introduced where an uninitialized `requestFut`
gets `fail()`-ed if the message's `id` cannot be found in pending list.
Revert back to return an `err()` instead, as before.
* Add framework to support more optional types
This PR add a framework to rpc server by using more templates than macros to handle optional types.
Now rpc server recognize both `std/options` and `results.Opt` as optional type for the parameters.
If needed user can add more optional types by overloading `rpc_isOptional` template.
Now aliases to optional types also works.
* Don't expose types used internally by the wrapper
* Improve resilience against null fields
* Fix client processMessage when handling error
* Improve both client and server resilience against fields and elements with null value
* Upgrade rpc router internals
* use new chronos asyncraises
* Fix style mismatch
* Fix nim v2 compilation error
* Addresing review
* Remove unnecessary custom serializer and let the library do the work
* fix error message
* Update readme.md
We currently only debug log successfully sent messages to RPC.
For debugging, it would be better to see the attempt and any failures.
Adjust logging to provide more information when debugging.
Also include the message name at debug level instead of just trace.
andri lim
Kim De Mey
Etan Kissling
tersec
coffeepots
Jacek Sieka