Closed erights closed 10 months ago
This looks like a new product feature. I'd like us to bring @sufyaankhan up to speed and get his take on it.
Documentation Considerations Let's get some road experience ourselves first.
Before merging it? Or before documenting it?
This looks like a new product feature. I'd like us to bring @sufyaankhan up to speed and get his take on it.
Absolutely! @sufyaankhan would love your thoughts.
Documentation Considerations Let's get some road experience ourselves first.
Before merging it? Or before documenting it?
Before documenting. We won't get enough road experience ourselves if we don't merge it first.
I have not yet made the suggested representation changes, so I reverted this PR to Draft.
Note to reviewers: Enough changed that it wasn't worth preserving old commits, so I squashed since you last reviewed.
Reviewers, Now that this is ready for review, I'll avoid further squashes without first asking you.
closes: #XXXX refs: #XXXX
Description
Given an environment variable setting of
then when
E
invokes agetAmountOf
method on an object with @@toStringTag of'Alleged: quatloos issuer'
, it should first execute a JavaScriptdebugger;
statement. When run normally, i.e., not under a debugger, thedebugger;
statement has no effect. But when run under a debugger, this statement acts as a breakpoint, causing execution to pause there.If the "*" at the end is replaced by a number, then each time execution matches, the number is decremented by 1. When it reaches zero, it executes
debugger;
.If the "getAmountOf" is replaced with "*", then it breakpoints on any method of a quatloos issuer.
If the "quatloos issuer" is replaced with "*", then it breakpoints on calling a method named "getAmountOf" on anything.
Similarly
will breakpoint when the message is eventually sent, so that you can look up the stack in the debugger to understand why it was sent. The name only matches if the object itself, or a remote presence for the object, is the target and so has the correct @@toStringTag. This does not work when eventually sending to a promise. To catch those cases, use "Promise" or "*" for the target name.
Security Considerations
As with all use of env-options, we should worry about whether an adversary can read or write these options, and so interfere with code that is supposed to use these options.
Scaling Considerations
If the
ENDO_DELIVERY_BREAKPOINTS
env-option is not even set, this implementation takes a fast path which should have essentially no penalty compared to the absence of these mechanisms.When
ENDO_DELIVERY_BREAKPOINTS
is present but has no "*" on the method name, we still try to minimize the overhead on non-matching method names. But once we have a method name match, then we do a linear search among these directives on each such call.Likewise for
ENDO_SEND_BREAKPOINTS
Documentation Considerations
Let's get some road experience ourselves first. But if it proves useful, it'll be a great debugging aid to explain.
It will be interesting to figure out how to show how to use it interactively from inside a debugger well, including dynamically changing breakpoints. Probably a short video?
Testing Considerations
Since this alters only the behavior seen from a debugger, it is unclear how to write an automated test.
Upgrade Considerations
None.