Skip to content

[@web/test-runner]: Logging complex (including circular) objects brings tests to a near-halt #2798

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

Open
rschristian opened this issue Aug 30, 2024 · 4 comments

Comments

@rschristian
Copy link

I'm running into an issue where wtr will slow to a near halt, usually timing out, upon encountering "complex" objects to log, which makes debugging tests considerably more difficult. Circular objects are sure to set it off (i.e., DOM nodes), but others with simply enough nesting will do it too. This also presents in the browser with --manual, I'm guessing due to something attempting to intercept all logs.

#1356 (comment) might be related and suggests this might be Mocha, but if so, are there any work arounds? Being able to quickly log a DOM node and other similarly "complex" objects to debug is a pretty crucial feature for my use, the current serializer, wherever it is, seems to really be struggling.

@rschristian
Copy link
Author

The serialization seems to also be so slow as to cause significant issues with our tests that (unfortunately) require forms of await sleep(...); logging of any object at all is often taking upwards of 10-20ms, which is pretty non-representative.

@rschristian
Copy link
Author

Running into this again today, this time, trying to log out Sinon calls. CPU hits 100% and Firefox tabs will crash. Very difficult to use.

@atjn
Copy link

atjn commented Mar 14, 2025

+1 this is causing all my tests to timeout because I do the simple check expect(htmlElement1).to.be(htmlElement2);.

I have tested it some more and it seems to work with elements that are not part of the DOM. See the following example:

const p1 = document.createElement("p");
const p2 = document.createElement("p");
document.body.appendChild(p2); // <- this is what makes the test timeout
expect(p1).to.equal(p2);

The above test will timeout, but if you remove line 3, it will work as expected and return: AssertionError: expected <p></p> to equal <p></p>.

@devversion
Copy link
Contributor

I'm also seeing this when printing complex class instances that have references back to the class instance. I wonder if it would make sense, or be sufficient to replace the custom replacer logic with e.g. https://www.npmjs.com/package/safe-stringify

devversion added a commit to devversion/web that referenced this issue May 5, 2025
…bjects

If we are seeing too many object iterations, we know something is off. This can
happen when we are seeing e.g. large linked lists where every element recursively
has access to the full list again. This will not quickly yield circular early bail-outs,
but instead result in the stringification to take LOTS of processing time and results
in browser crashes. We should limit object iterations for this reason, and instead expect
people to inspect such logs in the browser directly.

Related modernweb-dev#2798.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants