Opened 8 years ago
Closed 8 years ago
#27301 closed Cleanup/optimization (fixed)
Better handling of errors that are not pickleable when testing in parallel
Reported by: | Adam Wróbel | Owned by: | |
---|---|---|---|
Component: | Testing framework | Version: | 1.10 |
Severity: | Normal | Keywords: | testrunner parallel pickle |
Cc: | Aymeric Augustin, chris.jerdonek@… | Triage Stage: | Ready for checkin |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
When running test in parallel the tests results are communicated between processes in serialized form. Unfortunately not all test errors are serializable using pickle
module.
Django currently detects errors that fail pickle.dumps
, reports them to STDERR
and raises exception that interrupts test runner.
This ticket has two parts:
The first is a minor enhancement. In addition to detecting pickle.dumps
errors also detect pickle.loads
errors. I've implemented it in a Github PR #7325.
The second is a proposal to instead of raising pickling exception that interrupts tests and displays useless multiprocessing.pool.RemoteTraceback
wrap the error type and message in some kind of UnpickleableError
container and pass it to parent process with the usual addError
/addFailure
/addSubTest
/addExpectedFailure
methods. This will let the test suite continue, display final error statistics and perform teardown. This is especially important for addExpectedFailure
which currently stops the entire suite if the expected error is unpickleable (my actual use case).
Change History (13)
comment:1 by , 8 years ago
Owner: | removed |
---|---|
Status: | assigned → new |
Type: | Uncategorized → Cleanup/optimization |
comment:2 by , 8 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:3 by , 8 years ago
Cc: | added |
---|
follow-up: 5 comment:4 by , 8 years ago
comment:5 by , 8 years ago
Replying to Chris Jerdonek:
In the PR, you say--
One example of error like that is botocore.exceptions.ClientError which pickles as "ClientError(message)", but its initializer is actually ClientError(response, operation_name).
In addition to creating this ticket, have you also tried reporting this to the botocore project?
I've started writing a PR for botocore, but consider it a lower priority: we can try to fix thousands of unpickleable errors, but with a robust test runner it might not matter at all.
This ticket has two parts:
This sounds like it should be taken care of by two separate PR's (and indeed you created one PR to solve the first part). Does this mean you should have two separate tickets? This way the two issues can be discussed in isolation without confusing the two.
Indeed I could try to write a second PR if the second part of this ticket was accepted.
As for two tickets, I was really hoping to have that minor adjustment from first PR merged without any ticket at all. That one-direction-only check seems like a trivial omission. I think @aaugustin would agree.
follow-up: 7 comment:6 by , 8 years ago
I've started writing a PR for botocore, but consider it a lower priority:
Can you post a link to the issue?
we can try to fix thousands of unpickleable errors, but with a robust test runner it might not matter at all.
Thousands seems like an exaggeration to me. A dozen seems like a more likely upper bound.
In any case, if a particular exception isn't picklable, it seems like that should be reported as a bug each time we notice it -- regardless of the state of Django's test runner, and regardless of the number of instances we notice. Also, as long as Django relies on the picklability of exceptions for the nicest form of error messages, it seems we should want those exceptions to be picklable.
comment:7 by , 8 years ago
Replying to Chris Jerdonek:
I've started writing a PR for botocore, but consider it a lower priority:
Can you post a link to the issue?
Well, I said I started writing PR, not that I posted it. But hey, here's me hoping to please you:
https://github.com/boto/botocore/pull/1044
In either case botocore issue shouldn't in any way delay our progress here. They might fix it or not, but we should be able to handle problems like theirs.
comment:8 by , 8 years ago
I am beginning to think that making botocore
errors picklable is a lost cause. They support python 2.6 and 2.7 which is even worse at pickling (my current botocore PR only passes on 3.X). They also inherit exceptions from requests
package , similarly rewriting the __init__
signature and affecting picklability (I've accidentally omitted that one error class in my PR, but now I don't know how to tackle it).
comment:9 by , 8 years ago
Thanks. Re: botocore, it would seem reasonable to me for them to accept a PR that fixes it only for 3.x and/or future versions of botocore if fixing it for 2.x is too difficult and/or would break backwards compatibility.
Also, on a related note, if it turns out that picklability of exceptions is too much to expect in general, then I think we should consider not having Django's test runner error out if the exception isn't picklable. But that can be handled in the "part 2" ticket when that is created.
comment:10 by , 8 years ago
Has patch: | set |
---|---|
Triage Stage: | Accepted → Ready for checkin |
PR looks good to me. Wouldn't mind a +1 from someone else.
In the PR, you say--
In addition to creating this ticket, have you also tried reporting this to the botocore project?
This sounds like it should be taken care of by two separate PR's (and indeed you created one PR to solve the first part). Does this mean you should have two separate tickets? This way the two issues can be discussed in isolation without confusing the two.