Consider a max execution time parameter for all object traversal functions
AndrewJDR opened this issue · comments
Hi,
On the heels of an issue described here:
#990 (comment)
I became curious about whether rollbar.js has any mechanisms to prevent its traversal functions that are used for scrubbing custom data and serialization of custom data (merge, clone, etc) from blocking the event loop for very long (or even infinite) periods of time. This is probably an important thing to consider adding if it doesn't already exist, as otherwise, reporting an error via rollbar could cascade into complete lockup of the main event loop in node or browser contexts alike. Perhaps some maxCustomDataTraversalTime configuration parameter that causes any custom data traversal function to stop prematurely if their execution time exceeds the specified number of milliseconds? Another idea would be to use asynchronous processing of custom data...
I'll conclude with a question: If i were to add my own transform function, would this occur prior to rollbar's merge/clone calls, or after? I was considering writing my own function that limits the size/depth/etc of the data, but if transform is called after rollbar's merge/clone, this will occur too late, and any infinite loop/etc issues will already have occurred.
Tagging @waltjones for visibility
The user transform runs after scrubbing, so as you note, it would be too late.
As far as I know, all data added to the payload is already depth limited, except when a custom/extra object is added. Even when local variables are added in Node, those are also depth limited.
If the user were writing code for this, I'd handle it at the point where the data is attached. That code path knows the most about the structure of the data. Unlike a transform function, it would also not need to inspect every payload to find out whether the custom data is present or needs to be limited.
While it seems like the caller is empowered to handle this, I could see adding an internal check that runs with the circular reference check.
Hi @waltjones just an important heads up - Now that #990 is in versioned release, there exists a potential for hard lockups within rollbar due to some kind of infinite recursion -
#990 (comment)
If an internal depth or execution time check is too involved to implement, perhaps just reverting the circular reference commit for now might be best. In the event of a revert, it might be good to catch and swallow the RangeError: Maximum call stack size exceeded exception inside merge, and continue on while excluding the offending custom data from the rollbar request...
@AndrewJDR Any chance you have a minimal custom data object that causes this condition? This is tested with several kinds of recursive data. I'd like to figure out what's different about the object you're using.
@waltjones The condition only happens in our production environment, so it's a little tricky, but I'll try to find a way to capture it.