Essentially the question is should we remove previously set breakpoints after updating a module?
A. To me it feels natural to remove the breakpoint since conceptually updating a module means also starting from a fresh run in the VM and in that sense, I would expect that the VM does some cleanup before starting executing the new module. Part of the cleanup would be for instance, unsubscribing previous callback handlers of the previous module, removing breakpoints, and so on. If this is the direction we want to take, then updating the module should then also remove the breakpoints.
B. On the other hand, we could agree that breakpoints are only used when debugging. Consequently, if a user updates a module that probably means that a bug got fixed but the user may still want to continue debugging and thus the previously set breakpoints should still remain active.
If we go with A. then this is a bug easily fixable
If we go with B then this is not a bug and we can close this issue.
Essentially the question is should we remove previously set breakpoints after updating a module?
A. To me it feels natural to remove the breakpoint since conceptually updating a module means also starting from a fresh run in the VM and in that sense, I would expect that the VM does some cleanup before starting executing the new module. Part of the cleanup would be for instance, unsubscribing previous callback handlers of the previous module, removing breakpoints, and so on. If this is the direction we want to take, then updating the module should then also remove the breakpoints.
B. On the other hand, we could agree that breakpoints are only used when debugging. Consequently, if a user updates a module that probably means that a bug got fixed but the user may still want to continue debugging and thus the previously set breakpoints should still remain active.
If we go with A. then this is a bug easily fixable If we go with B then this is not a bug and we can close this issue.
@tolauwae what do you think?