Mon, 21 Apr 2014 16:13:15 -0700 bundle2: gracefully handle hook abort stable
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 21 Apr 2014 16:13:15 -0700] rev 21187
bundle2: gracefully handle hook abort We make sure any exceptions raised during the whole span of handling bundle2 processing are decorated. This let us catch exceptions raised by hooks prior to transaction commit.
Mon, 21 Apr 2014 17:51:58 -0700 bundle2: gracefully handle PushRaced error during unbundle stable
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 21 Apr 2014 17:51:58 -0700] rev 21186
bundle2: gracefully handle PushRaced error during unbundle Same drill again. We catch the PushRaced error, check if it cames from a bundle2 processing, if so we turn it into a bundle2 with a part transporting error information to be reraised client side.
Mon, 21 Apr 2014 20:04:54 -0700 bundle2: add an error message to push race error stable
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 21 Apr 2014 20:04:54 -0700] rev 21185
bundle2: add an error message to push race error Errors with no explanations makes my uncle Bob sad.
Mon, 21 Apr 2014 18:59:09 -0700 bundle2: fix raising errors during heads checking stable
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 21 Apr 2014 18:59:09 -0700] rev 21184
bundle2: fix raising errors during heads checking If the heads on the server differ from the ones reported seen by the client at bundle time, we raise a PushRaced exception. However, the part raising the exception was broken. To fix it, we move the PushRaced class in the error module so it can be accessible everywhere without an import cycle. A test is also added to prevent regression.
Mon, 21 Apr 2014 16:02:03 -0700 bundle2: gracefully handle UnknownPartError during unbundle stable
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 21 Apr 2014 16:02:03 -0700] rev 21183
bundle2: gracefully handle UnknownPartError during unbundle Same as for Abort error, we catch the error, encode it into a bundle2 reply (expected by the client) and stream this reply. The client processing of the error will raise the exception again.
Tue, 22 Apr 2014 11:41:34 -0700 bundle2: catch UnknownPartError during local push stable
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 22 Apr 2014 11:41:34 -0700] rev 21182
bundle2: catch UnknownPartError during local push When doing local push, UnknownPartError from the server will be raised directly to the client. We need to catch them too.
Mon, 21 Apr 2014 19:43:01 -0700 bundle2: catch UnknownPartError during pull stable
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 21 Apr 2014 19:43:01 -0700] rev 21181
bundle2: catch UnknownPartError during pull We narrow the exception catching while pulling.
Mon, 21 Apr 2014 19:42:51 -0700 bundle2: catch UnknownPartError during push stable
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 21 Apr 2014 19:42:51 -0700] rev 21180
bundle2: catch UnknownPartError during push We narrow the exception catching while unbundling the push reply.
Mon, 21 Apr 2014 19:42:40 -0700 bundle2: use a more specific UnknownPartError when no handler is found stable
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 21 Apr 2014 19:42:40 -0700] rev 21179
bundle2: use a more specific UnknownPartError when no handler is found KeyError is very generic, we need something more specific for proper error handling.
Mon, 21 Apr 2014 15:59:55 -0700 bundle2: make error testing more modular stable
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 21 Apr 2014 15:59:55 -0700] rev 21178
bundle2: make error testing more modular We have more than Abort to test.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 +30000 tip