fix: unify error serialization with config and other values. Fix err.onFai…

[AtofStryker]

…l issues

User facing changelog

n/a

Additional details

The goal of this PR is to fix the err.onFail is not a function bug we are seeing while writing multi-domain unit tests, as well as unify the error serialization across domains.

err.onFail was failing due to non serializable properties being stringified back to the primary domain, causing the error to fail. Instead of trying to send non serializable values as a serialized string, we now just omit these properties before sending the error (similar to env and config). Now that we process errors in the ran:domain:fn context, we need to also account for scenarios when throw 'oops' or something is thrown in the secondary that may/may not be an error object. This PR should cover this at a basic level.

I would have liked to use the structuredClone algorithm to clone Errors where applicable, but interestingly all properties declared on the error are removed when trying to clone, either with native Chrome implementations or the ponyfill. Once the Error is sent through postMessage, it loses it's prototype hierarchy and ultimately just becomes an object. Therefor, I figured the method we had to pre/post process errors how we do it now is likely preferable.

How has the user experience changed?

PR Tasks

• Have tests been added/updated?
• Has the original issue (or this PR, if no issue exists) been tagged with a release in ZenHub? (user-facing changes only)
• Has a PR for user-facing changes been opened in cypress-documentation?
• Have API changes been updated in the type definitions?
• Have new configuration options been added to the cypress.schema.json?

[cypress-bot]

Thanks for taking the time to open a PR!

• Create a Draft Pull Request if your PR is not ready for review. Mark the PR as Ready for Review when you're ready for a Cypress team member to review the PR.
• Become familiar with the Code Review Checklist for guidelines on coding standards and what needs to be done before a PR can be merged.

[cypress]

---

Test summary

19974 • 0 • 322 • 4 • 4

---

Run details

Project	cypress
Status	Passed
Commit	12b0769
Started	Feb 17, 2022 11:52 PM
Ended	Feb 18, 2022 12:05 AM
Duration	12:50 💡
OS	Linux Debian - 10.10
Browser	Multiple

View run in Cypress Dashboard ➡️

---

Flakiness

	commands/net_stubbing_spec.ts		3
1	network stubbing > intercepting response > can 'delay' a proxy response using Promise.delay
2	network stubbing > intercepting response > can 'delay' a proxy response using Promise.delay
3	network stubbing > waiting and aliasing > can timeout waiting on a single request using "alias.request"
	cypress/proxy-logging_spec.ts		1
1	Proxy Logging > request logging > xhr log has response body/status code

---

This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. You can manage this integration in this project's settings in the Cypress Dashboard

[AtofStryker]

This becomes a problem if someone tries to throw something that is unserializable. Do we think this is a valid concern?

[mjhenkes]

I think it is a valid concern. In general i think we should add a basic try-catch around postMessage for any unserializable data, so we can at least send a message with an error.

[mjhenkes]

It might be good to hold off on this PR until after #20247 lands.

[AtofStryker]

going to move this to draft until #20247 is merged in

[AtofStryker]

closing in favor of #20520