-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Description
Problem Statement
Currently UI breadcrumbs like ui.click only display ancestors for as long as doing so would take <= 80 characters.
| const MAX_OUTPUT_LEN = 80; |
This can be pretty limiting. If you have elements with many classes, long classnames, or wordy custom attributes that get sent thanks to serializeAttributes, then most breadcrumbs will only show one or two layers deep. Often it's the most helpful ancestor that has the most data that gets omitted because including it would push it over the 80 character limit.
It appears that the 80 character limit was set when ancestor UI breadcrumbs were first implemented in this commit from April 2016. In contrast, the Python sentry library appears to allow breadcrumb messages up to 1024 characters (first implemented here, current code here). I've verified that the js library can send a 1024 character breadcrumb today and that it displays properly in Sentry's UI.
If more characters were allowed, then my application's UI breadcrumbs would show more ancestor layers. This would make errors more actionable as it's more likely that an element's breadcrumb would have helpful info for understanding which exact element was interacted with.
Solution Brainstorm
The sentry js config could have a dom.maxStringLength option to allow consumers to choose their own maximum DOM serialized tree length. This value would be used in place of browser.ts's MAX_OUTPUT_LEN mentioned above, and it can default to 80 so that there is no effective change for existing users. Individual users can opt-in to longer DOM paths.
Currently, one workaround is to use beforeBreadcrumb to implement your own ancestor crawling and DOM serialization. Building in a dom.maxStringLength option is preferable to this workaround so that the ancestor crawling only happens once and so users can still rely on Sentry's built-in implementation.
It seems like the main constraining factor is the 1MB event size limit. As such, this new option should be subject to some maximum limit. I believe 1024 should keep it within the range unless in truly exceptional circumstances. Using 1024 as the max limit has the benefit of matching the Python implementation. The ancestor crawling is limited to a depth of 5, so all but the most extreme DOM elements would still report breadcrumbs much smaller than 1024 characters.