JSON RPC server callback return types post #708 cleanup

[majorpain1588]

Prior to the JSON RPC cleanup work in #708 in my server RPC methods I could return a result type or an rpc::error type. I know the docs show that you can return one or the other, but not both. It seems there isn't a way to have active code branches to return both like how it used to be possible using glz::unexpected.

My use case is to return an rpc::error if the input params are not valid and to return my result type if they are valid. When using the glz::expected return type this worked. Now that the glz::expected return type has been removed from the callback return I don't have a clear way to define my callback to be able to return both result and errors types without using some other wrapper type. I can return one or the other (like the docs illustrate), but not have return branches for both.

Example snippet:

glz::rpc::server<glz::rpc::method<"foo", foo_params, foo_result>  server;

server.on<"foo">(
    [log](foo_params const& params)
    {
        if (params.foo_a == 10) // dummy invalid param case
        {
            return glz::rpc::error{glz::rpc::error_e::invalid_params, "my error"};
        }
        else
        {
            // compiler error: 
            // "Return type 'foo_result' must match previous return type 'glz::rpc::error' when lambda expression has unspecified explicit return type"
            return foo_result{.foo_c = true, .foo_d = "new world"};   
        }
    }
);

I can get it to compile by wrapping my server return type in glz::expected and basically defining my callback the old way, but the response doesn't end up correct and I suspect that it just messes up the new behind the scenes code that is already doing that wrapping.

Any good ideas of how to handle this case now?

[stephenberry]

Ah, thanks for bringing this up. When I refactored the code I made it check at compile time for either an rpc::error or the result_t, so you're correct that this change blocks you from returning both in the same lambda. This can be fixed. I'll add the ability to also return a glz::expected, so that either a result or an error is returned.

I'm opening an issue from this. Thanks!

[stephenberry]

Fixed in #834

Example:

server.on<"foo">(
  [](const foo_params& params) -> glz::expected<foo_result, glz::rpc::error>
  {
      if (params.foo_a == 10) // dummy invalid param case
      {
          return glz::unexpected(glz::rpc::error{glz::rpc::error_e::invalid_params, "my error"});
      }
      else
      {
          return foo_result{.foo_c = true, .foo_d = "new world"};
      }
  }
);