Breakpoint should still be triggered even after Map Local

[CyberMew]

Map Local should be done first, then followed by Breakpoint.

The point of Breakpoint is for quick or adhoc changes. Regardless of the source response (http request or file), breakpoint should still do its job. (i.e. allow me to change http code, terminate request, etc) .

I now have to duplicate the Map Local file/rule 20 times and do slight modifications, and toggle between these 20 rules every single time I want to modify something. Each small modification = 1 file. That is a lot of clicks and time consuming (and wasting rules, my screen is full of the same rules and files). I don't know how to track them, it's crazy. If breakpoint is enabled for the endpoint, should not disable or bypass it as there is no reason to.

If the user don't want it to breakpoint, then they will uncheck the breakpoint rule. No harm done.

[NghiaTranUIT]

It makes sense. Like me take a look at how much workload to support the Breakpoint after Map Local.

To workaround, can you try using Scripting? You can import a JSON file as a body, and modify the header or the content of the file as you wish

[CyberMew]

That's actually the same as me creating a rule directly for each combination in Map Local, just that it's in code form 😂

[NghiaTranUIT]

Just wondering: Why don't you directly edit the map local file on the Editor rather than duplicating too many files?

Set a breakpoint, I assume you might change some param in the body or header-value, which is possible to directly edit on the Editor view.

[CyberMew]

It is more convenient for me. Breakpoint auto grabs my attention while going through my app flows, not only do I know something is correct (or wrong), I can also just resume it with just cmd+enter, or do a quick response body edit with just 1 click. With Map Local, I don't know when it is loading a local file, and it is a lot more work to edit the file, test my flow, then revert back the edit (I don't remember the previous changes). If I want to do a quick edit, it's more troublesome and a lot more work. Based on the different combinations the api endpoint is returning me, my app reacts differently. There are a total of more than 40 over scenarios. Sometimes I just need to modify some minor stuff based on a base scenario and it's overkill to fork/create 10 new scenario rule just for each base case and for that minor change when I just need breakpoint to confirm/modify the response body as per my testing. Either way, I feel breakpoint should still happen regardless of the source..

[NghiaTranUIT]

Thank you for the insight 😄 I'm working on it now and send you a BETA build this week 👍

[NghiaTranUIT]

Hey @CyberMew, let check out this BETA: https://proxyman.s3.us-east-2.amazonaws.com/beta/Proxyman_2.15.2_Breakpoint_After_Map_Local.dmg

From now, the flow will be mapped with the Map Local firstly, then mapping with Breakpoint (If it's matched any Breakpoint rules, which enables for Responses) 👍

[CyberMew]

Thanks, seems to be working good! Does it also breakpoint if Map Remote was set? Seem like it doesn't too..

[NghiaTranUIT]

You're right. I haven't implemented the Map Remote yet, but I will push it into the backlog 👍 If we have more requests, I will implement it 😄

[yberstad]

@NghiaTranUIT I'm very happy with you product, I use it almost every day.

I'm trying to use breakpoints combined with Map Remote, but cannot get it to work. I suspect that this is not implemented yet? I'm using the 2.18.0 version.

If you have the time to look into this, it would be much appreciated! 😄

Thanks in advance!

[NghiaTranUIT]

@yberstad Thank you for your kind word ❤️

Unfortunately, Map Remote doesn't work with the Breakpoint yet. I'm looking at it and try to implement it now and send you a BETA build this week 👍

[NghiaTranUIT]

To anyone who would try Map Remote and Breakpoint, let try this BETA build: https://github.com/ProxymanApp/Proxyman/issues/804#issuecomment-789560053 🙌