batch API endpoints can't return errors?

[bobdickinson]

I am trying to inderstand the philosophy of the batch APIs (copy_batch, delete_batch, move_batch).  I understand the general flow, but I am confused by the modality of these operations being able to complete immediately in some cases (returning a completion result on the initial call, eliminating the need to call the respective "/check" endpoint), but that they are unable to return an error under any circumstances.

So as a caller, I should expect either an immediation completion or a delayed completion (which I can then check on via the /check call), but in the case of an error, I *ONLY* get that on the /check call?  I'm not understanding why the batch calls wouldn't just return the normal kinds of errors when those errors are easy to determine at the time of the command, or when they would coorespond to whatever kind of operation you would otherwise complete without batching (the kind of case where you would return results instead of a job id).

[Greg-DB]

That's correct, the batch endpoints don't return errors themselves. These would only be returned by the check endpoints. I can't speak to why it's constructed this way, but I suspect it's just that the batch endpoints don't use the same mechanism as the non-batch endpoints and the error information isn't available at the time of the first call.

[bobdickinson]

I get that, and that would make total sense if these API endpoints didn't also have the ability to fully complete and return results without batching.

I guess my point is, if there is some set of circumstances that make the backend say "hey, this one looks easy, I don't need to batch it, I'll just do this real quick and return the result", OK, fine.  But if you encounter an error in that case, now all of the sudden that's something that requires a /check to get the completion (failure)?

I'd prefer they not even have the non-batch shortcut return mode and always just made you get the completion (or error) from /check.  That would make a lot more sense and make the client code path a lot simpler.

[Greg-DB]

Thanks for the feedback! I don't know what the specific conditions may be, but I'll send this feedback along to see if we can simplify this in the future.