Description of problem:

While addressing an unused variable warning/error for BZ 1369124, ndevos raises concerns about the handling of client_process_response() in client3_3_compound_cbk().

see comment in http://review.gluster.org/#/c/15482/7/xlators/protocol/client/src/client-rpc-fops.c

client_process_response() will only fail if the FOP is not supported in a COMPOUND, it's basically a coding bug when that happens.

The result of the compound would be in the args_cbk list, checking the result of the compounded-FOP and returning an error there would probably be better.

This isn't just an unused variable bug, the behaviour of a failed compunded-FOP needs to be documented. Would a single FOP failure abort execution of the rest of the COMPOUND? Should it result in a failure here too? The docs are not mentioning these kind of things, and I expect Krutika or Pranith to have some ideas about it.

https://github.com/gluster/glusterfs-specs/blob/master/under_review/compound-fops.md

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info: