currents-dev / cypress-debugger

Debug failed CI cypress tests with cloud-based replayable traces
https://cypress-debugger.dev
Other
52 stars 8 forks source link

[Feature] ability to configure when not to store response content #71

Open BloodyRain2k opened 9 months ago

BloodyRain2k commented 9 months ago

Description

I only recently started using the debugger, because I'm using Cypress for a SharePoint App project and the sheer amount of libraries that SharePoint throws at Cypress makes it literally impossible to debug more than one test at a time. And when using the runner I'm getting zero insight from Cypress why something failed. It's rarely something obvious and often something that failed silently a couple seconds before...

For now, this seems like my best chance at getting an idea afterwards, but I've noticed a different issue with this, also related to SharePoint's library bloat: it's storing every response too...

So it would be great if there could be an option added that allows to define a "mask" for requests where the content will not be stored in the dump.

Example usage

For example this request snipped from one of the logs:

"request": {
  "method": "GET",
  "url": "https://res-1.cdn.office.net/files/sp-client/sp-topic-sdk_none_18a84eb3923baa7170dd.js",
  ...
}

If I could define a filter like:

{
  "method": "GET",
  "url": /cdn\.office\.net/i,
}

then it could know that it doesn't need to write the response content of that request in the dump. And the url should use regex simply because this might be a simple example, but other junk might have a more complex pattern.

All other data like headers and status should be kept, as it might be valuable in the end to determine why something failed.

BloodyRain2k commented 9 months ago

Ok, I've spent the last day building a post processor to get rid of the "bloat" and found out that without that, the player has no idea anymore how to reconstruct the app. Not that surprising, considering that I'm ripping out dozens of megabytes of CSS...

Guess the debugger is already smart and only keeps the important stuff around and I just mistook it for SharePoint's junk. The feature itself might still be interesting in some way for someone eventually, but right now it's not for me anymore : /

Maybe a sort of consolidation of CSS specifically could help, but considering how long I spent with just a JSON stream processor without even getting "pretty printing" working, I doubt that this would be easy...