search

beyondcode / dusk-dashboard

A beautiful dashboard for your Laravel Dusk tests
https://pociot.dev/8-introducing-laravel-dusk-dashboard
MIT License
558 stars 62 forks source link

Truncated data when using debugbug bar #20

Closed mintbridge closed 8 months ago

mintbridge commented 5 years ago

If debug bar is enabled the amount of data coming back through the websocket means it gets truncated and fails to parse as json, i guess it would also happen with a really large amount of html

pdewit commented 5 years ago

Ran into this without using debugbar and a decent amount of html (more than 65kb), seems to be related to the max chunk size set in reactphp/stream:

https://github.com/reactphp/stream/blob/master/src/WritableResourceStream.php#L40

mbardelmeijer commented 5 years ago

Ran into this issue as well with a page which had a decent amount of HTML. JSON.parse failed on the client side and noticed that the JSON payload in the websocket is cut-off. Seems like what @pdewit is suggesting could be the cause, have tried to look into how to overrule this and create a PR but was unable to find a good solution.

Hopefully someone knows how to (easily) fix this.

Merry xmas! 🎄

PS: Awesome package btw, just what Dusk is missing: easy debugging!

Alexwijn commented 5 years ago

Any progress of fixing this issue? I just ran into the same issue, I guess my application is too large to run it with Laravel Dashboard. Got an average document size of 12kb.

robsontenorio commented 4 years ago

+1

Eight-Ball commented 4 years ago

+1

ncatanchin commented 4 years ago

Really like the look of this package and I've gotten very close to having it working, this problem is a difficult one! My Vue / Laravel app seems to have lot of CSS on the page - scoped css - which I have found difficult to solve with the Vue libraries in use.

I ended up added some code to filter out any inline <style> tags, still many pages are over 64k. I found where this limit is "set" in the related packages - tried to change the vendor code to at least see what happens and still it fails.

I'm toying with the idea of saving the html into a temporary file, returning the URL via socket, which can then be opened via HTTP by the frontend dashboard. Doesn't seem too bad an idea, might not be as fast, any thoughts?

Might even be interesting with regards to tracking changes - ideally your HTML should not change too much between test runs, unless the change is on purpose. The HTML from the previous run could be loaded in, then after the test runs it would be loaded again.