> ## Documentation Index
> Fetch the complete documentation index at: https://docs.molesignal.com/llms.txt
> Use this file to discover all available pages before exploring further.

# RUM errors and issues

> Group the errors of an application into issues with a state, a team, and a person, and see an issue that was resolved come back in a newer version.

**RUM → Errors** lists the errors of an application as issues. An issue is what the errors that are alike are one thing of.
It has a state, a team, a person who has it, and a record of when and in which versions it was seen. Every error stays in the
`rum_errors` stream with the id of its issue in `error.issue_id`, so the [explorer](https://docs.molesignal.com/en-US/rum/explorer.md) 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](https://docs.molesignal.com/en-US/rum/source-maps.md)),
* for a failed request, the method, the path, and the status code.

Numbers, UUIDs, hashes of eight or more hexadecimal digits, e-mail addresses, and the query string or fragment of a web
address are taken out of a message, so `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.

> [!NOTE]
>
> 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:

| Column | What it shows |
| - | - |
| **Issue** | The type and the message of the first error, and the first frame of the application's own code. |
| **State** | What is being done about it. See [states](#states). |
| **Assignee** | The person who has it, or the team when no person does. |
| **Sessions** | How many sessions met it in the time range. |
| **Users** | How many people met it. A visitor with no user id counts by the anonymous id of the SDK. |
| **Trend** | How often it happened in each of 12 equal parts of the time range. |
| **Versions** | The first version it was seen in and the latest. |
| **Last seen** | When it was last seen, over all time. |

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](https://docs.molesignal.com/en-US/rum/sampling.md#keep-every-error).

The type, the message, and the place an issue is listed with are kept as they were when its first error arrived, after the
masking rules of write time.

## States

| State | Meaning | Set by |
| - | - | - |
| **Open** | Nobody has looked at it. A new issue starts here. | The server, and a person. |
| **Investigating** | Someone is looking into it. | A person. |
| **Regressed** | It was resolved and came back in a newer version. | The server only. |
| **Resolved** | The cause is fixed. | A person. |
| **Ignored** | It needs nobody. | A person. |

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](https://docs.molesignal.com/en-US/rum/alerts.md) 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.query` opens the list and the issue.
* `rum.manage` sets the state, the team, and the person. Owners, administrators, and editors have it. Without it the controls only
  show what is set.

The endpoints are in the [RUM API](https://docs.molesignal.com/en-US/api/rum.md#issues).

> **[Source maps & symbols](https://docs.molesignal.com/en-US/rum/source-maps.md)**
>
> Restore the frames of an error so that issues are told by the code that threw them.

> **[RUM explorer](https://docs.molesignal.com/en-US/rum/explorer.md)**
>
> Search the errors of an issue with `error.issue_id`.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.