Merge lp:~gz/bzr/smarter_smart_error_reporting_722416_B into lp:bzr
Status: | Merged |
---|---|
Merged at revision: | 5694 |
Proposed branch: | lp:~gz/bzr/smarter_smart_error_reporting_722416_B |
Merge into: | lp:bzr |
Diff against target: |
245 lines (+95/-35) 5 files modified
bzrlib/remote.py (+21/-14) bzrlib/smart/message.py (+10/-20) bzrlib/smart/request.py (+3/-0) bzrlib/tests/test_remote.py (+58/-1) bzrlib/tests/test_smart_request.py (+3/-0) |
To merge this branch: | bzr merge lp:~gz/bzr/smarter_smart_error_reporting_722416_B |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
bzr-core | preliminary | Pending | |
Review via email: mp+51666@code.launchpad.net |
Description of the change
This is step 3 (really) in fixing bug 722416. The aim of the branch is to turn an remote response in the form `('MemoryError',)` into a useful message for the user. I'm pretty sure the code is incorrect or incomplete however.
I've got two main problems here. Firstly, there seem to be two different _translate_error functions for the local-side error interpretation. Secondly, I can only reproduce one of the codepaths from the bug reports in the tests.
The stack I can test is going through autopack as-like bug 602614, which uses the bzrlib.
Note re-raising MemoryError locally isn't what we want to do, that's not the starving python. A new error class could be created though. Is there any additional 'advice' it would be useful to show to the user? Perhaps a suggestion to try the operation again locally or with 'nosmart+' instead?
Martin [gz] wrote: remote. _translate_ error function. However, I think the one I really smart.message. _translate_ error but I'm failing to
[...]
> This is step 3 (really) in fixing bug 722416. The aim of the branch is to turn
> an remote response in the form `('MemoryError',)` into a useful message for
> the user. I'm pretty sure the code is incorrect or incomplete however.
>
> I've got two main problems here. Firstly, there seem to be two different
> _translate_error functions for the local-side error interpretation. Secondly,
> I can only reproduce one of the codepaths from the bug reports in the tests.
>
> The stack I can test is going through autopack as-like bug 602614, which uses
> the bzrlib.
> need to patch is the bzrlib.
> write a test with a stack like the local-side one in bug 721598 as the
> important bits in test_remote seem to be Fake'd out. Help?
Hmm. I don't think we have good unit tests for smart.message. _translate_ error. Well, we do have ingProtocolThre e in test_smart_ transport, which currently tests erver paths there, but via the byte-level
bzrlib.
TestClientDecod
the UnknownMethod and ErrorFromSmartS
details of the v3 protocol which you don't really want to care about for this.
I suspect the other paths are only exercised incidentally via the broader test
suite.
The intent was that message. _translate_ error would be for all the context-free _translate_ error. So _translate_ error is probably the better place.
error translations, i.e. error translations that are independent of the request
that triggered them, such as UnknownMethod. Then the translations that want
access to the branch object or whatever belong in remote.
you're right that message.
I'm not sure the distinction is particularly important, and looking at it with _translate_ error erver are _translate_ error _translate_ error will see it
relatively fresh eyes it has the drawback that the message.
function is never used by v2 (or v1, but it has a fixed set of error names
anyway), and so the cases other than UnknownMethod and ErrorFromSmartS
thus duplicated anyway. I'm also not sure that drawback matters much though,
although worryingly NoSuchFile has richer behaviour in remote.
that will never be triggered in v3 because message.
first.
We have good unit tests I think that the protocol layer signals the presence of _translate_ error (at a glance I see ationSuccess is missing one or two newer errors like NotStacked). _translate_ error. I think the
an error to its caller, and from the other end test_remote does pretty good job
of unit testing remote.
TestErrorTransl
But as you've noticed there's a gap for message.
ideal solution is to write the unit tests for that gap, but I don't want to
force you to do that just for this fix. Hmm :/
I'm currently inclined to say:
* leave the UnknownMethod and ErrorFromSmartS erver paths in _translate_ error: they probably do belong there, and are already well _translate_ error
message.
tested.
* move the context-free translations into a new function, probably in remote.py
* invoke that new function as part of remote.
This I think satisfies all the concerns adequately:
* the context-free translations don't clutter up the more complex...