-
-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix xunit and json reporter crash when used with parallel mode #4623
Conversation
14be642
to
8261ea8
Compare
Oops. Need to figure out the CLA first. Closing the PR for now. |
8261ea8
to
3ff1254
Compare
Reactivating PR and rebased after signing CLA |
+1 |
This change would be very helpful for our organization. Any idea when this PR might pick up traction? |
@curtisman thank you for this PR. Sorry for the delay, are you still around? The communication between processes (IPC) with its de-/serialization is a time-costly matter. We have to be very selective with the data we are transmitting, otherwise the parallel mode turns out to be slower than a serial run.
This is too generous. I will have a look which properties we will need. At a first look, adding just |
3ff1254
to
cbbcc0f
Compare
@juergba I reverted the change to fully serialized nested objects. Although, I feel like this will just turn in the whack-a-mole, as I don't think there is a good documentation on what reporter are expected to have access to in these objects, and other reporters might us a fuller set of data here. I am wondering how much these extra data actually cost. Additionally, I tested out my original repro in #4453 (comment) with the |
Yes, I feel the same way. This entire IPC implementation with its de-/serialization appears so clumsy to me. "speed" is the only argument which could justify the additional maintenance burden we have with So be prepared for more nagging on your JSON fix. |
I totally hear you there. For now, I am fully ok with just getting this PR in following the pattern of what is there already, to fix the bug to unblock people. I poked around the code a little bit (specifically deserialization), and there are some pretty easy improvements that can be made to speed that part up, but I don't know whether it will have any effect on the overall scenarios that people care about. What scenarios are we looking at for measuring speed? Any data on which part of it causing speed issues (serialization? deserialization? IPC between worker and main process? contention on the main process when receiving IPC?...) |
yes please, go ahead, your PRs are very welcome.
Nothing sophisticated, just the total time. The user sitting in front of his/her terminal: serial vs parallel. I can recommend to read:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@curtisman thank you!
No tests are ok for now. There will be more parallel
fixes to come anyway.
Requirements
Description of the Change
See this comment #4453 (comment)
This change fixes the various issue encountered when using parallel mode with the
xunit
andjson
reporter when error happens.All the changes are in
Test
,Suite
andHook
's serialize function$$isPending
toboolean
to remove the possibility that it isundefined
which is not serialized.Hook.prototype.serialized()
:state
,file
,duration
,fullTitle()
,currentRetry()
in the base objectparent.fullTitle()
in theparent
objectWhy should this be in core?
Fixes broken functionality in the core
Benefits
xunit
andjson
reporter can be used in parallel modePossible Drawbacks
I didn't fully look at all the possible reporters mentioned in #4453 and more fixes may be needed to address the full scope.
Applicable issues
Fix #4624
Partial bug fix to #4453