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

Durham Goode durham at fb.com
Thu Aug 6 17:09:14 CDT 2015



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>?


More information about the Mercurial-devel mailing list