[PATCH remotefilelog-ext getfile-errors] getfile: add error reporting to getfile method

[Augie Fackler]

> On Aug 6, 2015, at 6:09 PM, Durham Goode <durham at fb.com> wrote:
> 
> 
> 
> On 8/4/15 12:35 PM, Augie Fackler wrote:
>> # HG changeset patch
>> # User Augie Fackler <augie at google.com>
>> # Date 1438714793 14400
>> #      Tue Aug 04 14:59:53 2015 -0400
>> # Node ID 77e2a6bed76ff7bf337b40f8e02b723d3a3d328f
>> # Parent  73bc61b89e758824232c8eddd3ecdf0ae2b2880d
>> getfile: add error reporting to getfile method
>> 
>> Without this, the only way to report a failure of a file load in a
>> batched set of getfile requests is to fail the entire batch, which is
>> potentially painful. Instead, add our own error reporting in-band
>> which the client can then detect and raise.
>> 
>> I'm not completely happy with the somewhat adhoc error reporting here,
>> but we expect our server to have at least one additional error ("not
>> allowed to see file contents") which will require some special
>> handling on our end, so we need some level of flexibility in the error
>> reporting protocol so we can extend it later. Sigh.
>> 
>> Open question: should we reserve some range of error codes so that
>> it's easy for strange custom servers to have related monkeypatches to
>> client code for custom handling of unforseen-by-remotefilelog
>> conditions?
>> 
>> I couldn't figure out how to actually get the client to try loading
>> file contents over http in the test, but the get-with-headers test at
>> least proves that the server responses look the way I expect.
> Generally looks good.  I'll add a doc comment documenting the protocol and I'll queue it.  Any reason you chose the <stringint>\0<data> protocol instead of <binaryint><data>?

A mix of laziness, misguided hope for future extensibility, and consistency with the lookup wireproto command. Mostly laziness, I guess.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20150806/ed9bec65/attachment.pgp>