Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
libflux: allow error string in RPC response #1538
As discussed in #796, this PR adds the capability to return an error string in an RPC response, adding these API functions:
// mainly used in unit tests like other similar functions int flux_response_decode_error (const flux_msg_t *msg, const char *errstr); flux_msg_t *flux_response_encode_error (const char *topic, int errnum, const char *errstr); // respond with error: errnum != 0 required, errstr != NULL optional int flux_respond_error (flux_t *h, const flux_msg_t *msg, int errnum, const char *errstr);
// Get error message from fulfilled RPC future // Never NULL - if no error string in response, returns flux_strerror (errnum) const char *flux_rpc_get_error (flux_future_t *f);
So one might write RPC client code that looks like this:
if (!(f = flux_rpc (h, ....))) fatal ("flux_rpc failed"); if (flux_rpc_get (f, "foo.method", ...) < 0) fatal ("foo.method: %s", flux_rpc_get_error (f)) ...
In addition, relax some API calls that take "JSON strings" to allow any string, for flexibility (ostensibly to add error string payload to response, but this seemed like a good general improvement):
Finally, I thought now that we have
Todo: add new functions to man pages, revisit testing, probably some PR comment improvement.
@@ Coverage Diff @@ ## master #1538 +/- ## ========================================= Coverage ? 78.89% ========================================= Files ? 166 Lines ? 30598 Branches ? 0 ========================================= Hits ? 24140 Misses ? 6458 Partials ? 0
referenced this pull request
May 28, 2018
Is there a reason not to have a variadic
int flux_respond_error (flux_t *h, const flux_msg_t *msg, int errnum, const char *fmt, ...);
This might help in many RPC response error paths where it would be awkward to create formatted error messages (and the code would be difficult to test as well), but you may have already considered this and have some arguments against the implementation.
Just pushed that change - I'll squash if it looks OK.
I vsnprintf()ed the message into a 1K-byte static buffer, silently truncating. Any problem with that? I could go with vasprintf() if you think that's better. I thought since we recommend 80 chars or less in the RFC, truncating at 1K would be OK and another malloc saved (albeit in an uncommon case).
Looks good! As a test I added a check for
$ flux wreckrun -n 0 hostnanme wreckrun: flux.rpc: Invalid value for required job parameter ntasks (got 0)