rum_errors stream with the id of its issue in error.issue_id, so the explorer and queries see both.
How errors become issues
The server works out the issue of an error when the error arrives. The id is a hash of:- the application and
error.source, - the type, the category, and the message of the error with the parts that change from one error to the next taken out,
- the first three frames of the application’s own code, as resolved by the source map, mapping, or symbol file of the release when one is uploaded (see source maps and symbols),
- for a failed request, the method, the path, and the status code.
Loading chunk 482 failed. and Loading chunk 17 failed. are one issue. A frame of a
package, a framework, or the runtime is not the application’s own code, and does not count while the application has frames of
its own.
Send error.fingerprint (up to 128 characters) to group errors another way. Errors of one application that name the same
fingerprint are one issue, whatever their messages and stacks. The SDKs do not set it; pass it in the call that reports the
error.
The rules that make the id are versioned. A later change of how errors are grouped gives new ids, so an issue
that exists is never regrouped in place. Errors that arrived before the issues were kept have no
error.issue_id and are not
listed. An error that arrives before the source map of its release is uploaded is grouped by its original frames, and one that
arrives after by its restored frames: the same problem can be two issues. Issues that exist are not merged.The list
The list shows the issues with errors in the time range, of one application and one environment. Each row shows:
By default the list shows the issues that are Unresolved: open, investigating, or regressed. Choose another state, or
All issues, in the filter. Narrow the list by words in the type, the message, or the place; by the person who has the issue; and,
when more than one kind of client sent errors, by the source. Click State, Sessions, Users, or Last seen to order the rows,
and click again to reverse them. The state of the page is in the address, so a view can be shared.
The list reads the 250 issues with the most sessions (or users, or occurrences, by the order chosen) and narrows them by
the filters, so a filter never reaches an issue below them. At most 100 issues are shown.
Where it happens above the list spreads the sessions of the listed issues over their versions, their pages, and
their browsers. Click a value to narrow the list to the errors that happened there. Every column narrows with it. Click the
value again to let go.
The issue
Click a row to open the issue in a drawer. Its address holds the issue, so the drawer opens again from the address.- The head sets the state, the team, and the person who has it. View in Explorer opens the explorer on the errors of the issue.
- The facts line shows the state, the sessions and the people in the time range, when the issue was first and last seen, and its versions.
- Over time shows the sessions of the last 14 days, by day and stacked by version. A dashed line marks the day the issue was resolved.
- Where it happens spreads the sessions of this issue over browsers, systems, and countries.
- Where it was thrown lists the frames of the latest error that has a stack: the application’s own frames in strong type, the libraries’ dimmed. When a debug artifact restored the frames, switch between Restored and Original.
- Latest sessions lists the last three sessions that met the issue with the way into the replay and the timeline of each, and People affected the people who met it most often. An error of a session that was not kept is kept alone, so it says Session not kept where the way into the session would be. See RUM data sampling.
States
Open, investigating, and regressed issues are unresolved.
Regression
Resolving an issue records the time, the person, and the newest version the application had at the time. Versions are ordered by the time each was first seen, whatever they are called. An error of a resolved issue reopens it as Regressed only when the error is in a version first seen later than that one. Users who did not update keep meeting the old version, and an error in the same or an older version never reopens the issue. An application that sends no version has no order to go by: any error after the resolving reopens the issue. An error that names no version does not reopen an issue that was resolved in a version. Changing the state of a regressed issue ends the regression. Resolving it again records the newest version again. An issue belongs to the whole application, in every environment. The server keeps the environment of the error that reopened it, and the first time each environment saw the issue. Alert rules use them to count the new and the regressed issues of one environment. The part of the server that receives the errors remembers an issue for up to a minute, so a state a person sets reaches it within that minute. An error in a newer version that arrives while it still remembers the old state does not reopen the issue; the next error after the minute does.New issues an hour
An application opens at most New issues an hour new issues in an hour, 100 by default. Past that, the errors of the rest of the hour that belong to no issue yet are counted together as one issue named Other errors, so that an application whose messages never repeat cannot fill the list. Change the number in the application: RUM → Applications, the Issues section, between 1 and 10,000. A change applies within half a minute.Permissions
streams.queryopens the list and the issue.rum.managesets the state, the team, and the person. Owners, administrators, and editors have it. Without it the controls only show what is set.
Source maps & symbols
Restore the frames of an error so that issues are told by the code that threw them.
RUM explorer
Search the errors of an issue with
error.issue_id.