Skip to content
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

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

Open
BloodyRain2k opened this issue Nov 29, 2023 · 1 comment
Open
Labels
enhancement New feature or request

Comments

@BloodyRain2k
Copy link

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 BloodyRain2k added the enhancement New feature or request label Nov 29, 2023
@BloodyRain2k
Copy link
Author

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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant