> ## Documentation Index
> Fetch the complete documentation index at: https://docs.flashduty.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Error Grouping
> Learn about RUM error grouping mechanisms to improve Issue localization efficiency.
When a new error event occurs, Flashduty uses a three-step aggregation strategy to group errors into Issues, effectively reducing the number of errors that need to be handled.
## Grouping Process
Get the fingerprint of the error event and compare it with fingerprints of existing Issues
If the new event shares the same fingerprint as an existing Issue, it is automatically grouped into that Issue
If the fingerprint doesn't match, machine learning models analyze error similarity and group the event into the Issue with the highest similarity, or create a new Issue if similarity is too low.
**Android NDK native crash exception:** NDK native crashes (where `source_type` contains `ndk`, or the stack contains application-layer native frames) skip the ML similarity analysis in this step and rely entirely on the deterministic fingerprint from Step 1. This is because NDK crash messages (such as `signal: SIGSEGV`) are nearly identical across unrelated crashes; routing them through similarity analysis would incorrectly merge crashes from different code locations into the same Issue. The frame-aware fingerprint precisely distinguishes different crash sites.
## Default Fingerprint
Flashduty enables error grouping by default, working without additional configuration. The Browser SDK automatically collects error data and performs grouping.
Include the Flashduty Browser SDK in your HTML file:
```html theme={null}
```
When initializing the SDK, specify the application ID and environment:
```javascript theme={null}
window.FLASHCAT_RUM.init({
applicationId: "rum-application-id",
environment: "production",
version: "1.0.0",
});
```
### Fingerprint Calculation Rules
When an error event doesn't carry a fingerprint, Flashduty automatically calculates one based on the following error attributes:
| Attribute | Description |
| --------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `service` | Service where the error occurred |
| `env` | Environment where the error occurred |
| `error.type` | Error type classification |
| `error.message` | Error description text. For Android NDK native crashes, this component is augmented with the topmost application-layer native frame from the stack, in the format `\|native::` (for example, `signal: SIGSEGV\|native:libmyapp.so:crash_func+48`). System library frames (`libc.so`, `libart.so`, etc.) and pseudo-mappings (`[vdso]`, `[stack]`) are skipped, ensuring the same crash location always produces the same fingerprint across different runs. |
To improve grouping accuracy, Flashduty removes variable attributes from stack frames, such as version numbers, IDs, dates, and other dynamic parameters.
## Custom Fingerprint
If default grouping doesn't meet your needs, you can fully control error grouping behavior by providing a custom fingerprint.
Custom fingerprints take priority over default fingerprints.
When manually reporting errors, add a custom fingerprint via `addError`:
```javascript theme={null}
window.FLASHCAT_RUM.addError(new Error("My error message"), {
source: "custom",
fingerprint: "my-custom-grouping-fingerprint",
});
```
Dynamically set fingerprints via the `beforeSend` callback:
```javascript theme={null}
window.FLASHCAT_RUM.init({
applicationId: "rum-application-id",
environment: "production",
beforeSend: (event) => {
if (event.type === "error") {
event.error.fingerprint = "my-custom-grouping-fingerprint";
}
return true;
},
});
```
* Custom fingerprint must be a string type
* Errors with the same fingerprint within the same service will be grouped into the same Issue
* Errors from different services will be grouped into different Issues even if they have the same fingerprint
* The `beforeSend` callback can also be used to filter irrelevant errors (such as third-party script errors)
## Web-Specific Considerations
Upload `sourcemap` files to decode minified stack traces, ensuring grouped error stacks can be mapped to original source code.
```bash theme={null}
flashcat-cli sourcemaps upload \
--service my-service \
--release-version 1.0.0 \
--minified-path-prefix /assets \
--api-key your-api-key \
./dist
```
By default, Flashduty filters errors from browser extensions or third-party scripts (such as `network` source) to reduce noise.
You can further customize filtering rules via `beforeSend`:
```javascript theme={null}
beforeSend: (event) => {
if (
event.error.source === "network" &&
event.error.message.includes("ThirdPartyScript")
) {
return false; // Discard this error
}
return true;
};
```
## View Grouping Results
In the Flashduty platform, navigate to "Error Tracking" to view the grouped Issue list.
Each Issue contains:
| Content | Description |
| ----------------------------- | --------------------------------------------------------------- |
| Error message and stack trace | If `sourcemap` is uploaded, shows original source code location |
| User session timeline | Operation path that triggered the error |
| Metadata | Browser type, version number, etc. |
## Next Steps
Learn about Issue status transition mechanisms