Duplicate Issues for same event

[anirudhsama]

OS:

• Windows
• MacOS
• Linux

Platform:

• iOS
• Android

SDK:

• @sentry/react-native (>= 1.0.0)
• react-native-sentry (<= 0.43.2)

SDK version: 5.26.0

react-native version: 0.74.3

Are you using Expo?

• Yes
• No

Are you using sentry.io or on-premise?

• sentry.io (SaaS)
• on-premise

If you are using sentry.io, please post a link to your issue so we can take a look:

[Link to issue]
https://lounge.sentry.io/issues/5631745136/?project=4505006490058752
https://lounge.sentry.io/issues/5634175537/?project=4505006490058752
https://lounge.sentry.io/issues/5630881604/?project=4505006490058752
https://lounge.sentry.io/issues/5632068281/?project=4505006490058752
https://lounge.sentry.io/issues/5625357376/?project=4505006490058752

Configuration:

(@sentry/react-native)

Sentry.init({
	dsn: Env.SENTRY_DSN,
	tracesSampleRate: 0.01,
	enabled: !__DEV__,
	debug: __DEV__,
	enableNdkScopeSync: true,
	integrations: [new Sentry.ReactNativeTracing({ routingInstrumentation })],
	// only sample transaction events for paid users
	beforeSendTransaction: (event) => {
		if (event.user && event.user.is_paid) {
			return event;
		}

		return null;
	},
});

Sentry.configureScope((scope) => {
	scope.setTag("expo-update-id", Updates.updateId);
	scope.setTag("expo-is-embedded-update", Updates.isEmbeddedLaunch);

	if (typeof updateGroup === "string") {
		scope.setTag("expo-update-group-id", updateGroup);

		const owner = extra?.expoClient?.owner ?? "[account]";
		const slug = extra?.expoClient?.slug ?? "[project]";
		scope.setTag(
			"expo-update-debug-url",
			`https://expo.dev/accounts/${owner}/projects/${slug}/updates/${updateGroup}`,
		);
	} else if (Updates.isEmbeddedLaunch) {
		// This will be `true` if the update is the one embedded in the build, and not one downloaded from the updates server.
		scope.setTag(
			"expo-update-debug-url",
			"not applicable for embedded updates",
		);
	}
});

metro.config.js

// Learn more https://docs.expo.dev/guides/monorepos
// Learn more https://docs.expo.io/guides/customizing-metro
/**
 * @type {import('expo/metro-config')}
 */
const { getSentryExpoConfig } = require("@sentry/react-native/metro");
const path = require("path");

// Find the project and workspace directories
const projectRoot = __dirname;
// This can be replaced with `find-yarn-workspace-root`
const workspaceRoot = path.resolve(projectRoot, "../..");

const config = getSentryExpoConfig(projectRoot);

// 1. Watch all files within the monorepo
config.watchFolders = [workspaceRoot];
// 2. Let Metro know where to resolve packages and in what order
config.resolver.nodeModulesPaths = [
	path.resolve(projectRoot, "node_modules"),
	path.resolve(workspaceRoot, "node_modules"),
];
// 3. Force Metro to resolve (sub)dependencies only from the `nodeModulesPaths`
config.resolver.disableHierarchicalLookup = true;

// Enable Inline Requires https://x.com/dan_abramov2/status/1761497722371137717
config.transformer.getTransformOptions = async () => ({
	transform: {
		inlineRequires: true,
	},
});

module.exports = config;

In case of EAS Updates, we upload the source maps using sentry-expo-upload-sourcemaps. Sample command:

bun run eas update --branch production --message "HW Help fixes" && bun x sentry-expo-upload-sourcemaps dist

---

I have the following issue:

We are using Sentry.captureMessage to send an event whenever an API times out on the app. Somehow this results in having multiple different Issues created on Sentry. I have attached the screenshot showing multiple issues across app versions.

Steps to reproduce:

// Log the error to Sentry
if (error instanceof ClientTimeoutError) {
	Burnt.alert({
		title: "Request timed out, check internet and try again",
		preset: "error",
		message: "Please try again!",
		duration: 2,
	});

	Sentry.captureMessage("Client API Timeout", {
		contexts: {
			request: {
				url,
			},
		},
		tags: {
			timeout: true,
			path: options.dynamicPathIdentifier || path,
			timeout_value: error.timeout / 1000,
			retry_count: error.retryCount,
			method: options.method,
		},
		level: "warning",
	});
}

Actual result:

There are multiple issues being created for this event.

Expected result:

We expect only one issue to be created.

[kahest]

Hey @anirudhsama thanks for the detailed report! We'll dig through the information and follow up here with questions and findings.

[armenzg]

This is not using the message for grouping but the thread stack trace.

Is it normal for the filename to change so often?

[armenzg]

If you opted-in your org as an early adopter we can investigate if our new AI grouping would help in your case.

[anirudhsama]

The source maps are uploaded, so shouldn't the file name be taken from the that? Im seeing that in that event, somehow source map isn't available. But in another error which is running the same bundle (hot push via EAS Update) the source map is available.

Client API Timeout event ID: 3f724b60d16c4e7da9fed3a66a2b05ca - no source maps available
Another error event ID: 639e21c5dbef4f178c958c7c38833713 - source maps available