feat(errortracking): ignoredExceptionTypes config to skip RN-duplicate JS errors

[tsushanth]

Summary

Closes #567.

In React Native apps that enable native crash autocapture, a fatal JS error is captured twice:

1. The JS layer captures it via uncaughtExceptions autocapture (with the JS stack trace), and
2. React Native rethrows the same fatal JS error on the native side as com.facebook.react.common.JavascriptException. posthog-android's uncaught-exception handler then captures it as a second $exception event (with a native stack trace).

The result is two $exception events for one logical error.

API

New optional field on PostHogErrorTrackingConfig:

public val ignoredExceptionTypes: MutableList<String> = mutableListOf()

Setup in an RN app:

PostHogAndroidConfig(apiKey).apply {
    errorTrackingConfig.ignoredExceptionTypes.add(
        "com.facebook.react.common.JavascriptException",
    )
}

Whenever the uncaught-exception handler fires, the throwable and every cause in its chain are checked against the list by class name:

• If any link matches → the SDK skips emitting \$exception, but still chains to the next handler (so the process termination / RN red-box / etc. behave the same way as before).
• If nothing matches (or the list is empty, the default) → behavior is unchanged.

Mirrors sentry-android's addIgnoredExceptionForType(...).

Implementation notes

• Class-name based, never Class<*>::isInstance. This is deliberate: matching by name means apps that don't have React Native (or any other optional dependency) on their classpath are not affected at startup or call time. The SDK never has to load or even know about RN's types — the consumer just passes the FQCN string.
• Cause-chain walk. Real RN apps sometimes wrap the JS exception in a platform-level wrapper before it reaches the uncaught handler, so the check walks cause until either a match is found or a seen-set short-circuits a self-referential chain.
• Always chains. The defaultExceptionHandler is always invoked, ignored or not. The contract of Thread.UncaughtExceptionHandler (process termination, RN's red-box, etc.) shouldn't change based on whether we emit a \$exception event.
• No public API removed. Pure additive change. Apps that don't set ignoredExceptionTypes see zero behavior difference.

Tests

Three new tests in PostHogErrorTrackingAutoCaptureIntegrationTest:

• uncaughtException skips capture when throwable class is in ignoredExceptionTypes — direct match.
• uncaughtException skips capture when ignored class is anywhere in the cause chain — RuntimeException("outer", cause = JsException). The outermost type is not in the list, but the chain match still suppresses.
• uncaughtException still captures when throwable class is not in ignoredExceptionTypes — guards against the strip widening to all throwables when the list is non-empty.

The RN exception type is stubbed locally (ReactNativeJavascriptExceptionStub) so the test doesn't drag React Native into the SDK's test classpath — the name-based check exercises the same code path either way.

All 17 tests pass (14 existing + 3 new):

> Task :posthog:test
BUILD SUCCESSFUL in 22s

Test plan

• ./gradlew :posthog:test --tests "com.posthog.errortracking.*" — 17/17 pass
• ./gradlew :posthog:compileDebugKotlin (via the test task) — clean
• Manual verification: with ignoredExceptionTypes = [], all existing tests behave identically (no behavior change to the autocapture path).

Sibling issue

A matching fix is needed on the iOS side per #653 (RN rethrows fatal JS as RCTFatalException). Happy to ship that next as a separate PR if this shape is what you want — the iOS surface would be PostHogErrorTrackingConfig.ignoredExceptionNames: [String] with the same cause-chain walk.

Notes for review

@marandaneto — you suggested beforeSend as a "for now" workaround on the issue thread; this PR proposes the structural fix. Naming and scope are intentionally narrow: just the FQCN list, no Class-object overload, no auto-detection of RN. Happy to refactor if you'd rather keep the surface even smaller (e.g. hardcode the JavascriptException class internally and gate on an RN-detection bool) — let me know which shape you'd prefer.

[greptile-apps]

Prompt To Fix All With AI

Fix the following 3 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 3
posthog/src/main/java/com/posthog/errortracking/PostHogErrorTrackingAutoCaptureIntegration.kt:88-92
When the cause chain is what triggered the skip (not the direct throwable), this log reports the outer wrapper's class name — e.g. `java.lang.RuntimeException` — even though that class is not in `ignoredExceptionTypes`. A developer looking at these logs would wonder why `RuntimeException` was suppressed, since they only configured `com.facebook.react.common.JavascriptException`. Logging `throwable.javaClass.name` is only accurate when the outermost exception matched; the message should be phrased to cover the cause-chain case too.

```suggestion
            } else {
                config.logger.log(
                    "Skipping autocapture: ${throwable.javaClass.name} (or a cause in its chain) matches ignoredExceptionTypes",
                )
            }
```

### Issue 2 of 3
posthog/src/test/java/com/posthog/errortracking/PostHogErrorTrackingAutoCaptureIntegrationTest.kt:157-226
Prefer parameterised tests — the three new tests share identical setup (`remoteConfigHolder`, `isAutocaptureExceptionsEnabled`, `getDefaultUncaughtExceptionHandler`) and verify the same contract with different inputs. At minimum, the "skips capture" (direct match) and "still captures" (no match) cases are a natural `@ParameterizedTest` pair: the only axes that vary are the throwable type, the ignored-list contents, and whether `captureException` is expected to be called. Collapsing them reduces boilerplate and makes it immediately clear when a new edge case is added that it's intentionally distinct from existing ones. The cause-chain test is structurally different enough to stay standalone.

### Issue 3 of 3
posthog/src/test/java/com/posthog/errortracking/PostHogErrorTrackingAutoCaptureIntegrationTest.kt:228-234
The comment says "a local class named the same way", but the stub's actual JVM name is `com.posthog.errortracking.PostHogErrorTrackingAutoCaptureIntegrationTest$ReactNativeJavascriptExceptionStub` — nothing like `com.facebook.react.common.JavascriptException`. The tests work correctly because they pass `ReactNativeJavascriptExceptionStub::class.java.name` as the filter value, not the real RN FQCN. The comment should reflect the actual design: a stub with an arbitrary local name, registered under that same local name, so the name-based matching code path is exercised correctly without pulling in the RN dependency.

```suggestion
    /**
     * Local stand-in for `com.facebook.react.common.JavascriptException`. The real type
     * lives in React Native, which isn't (and shouldn't be) a test dependency of the
     * SDK. The ignored-exception filter is purely class-name based: tests register this
     * stub's own JVM name as the ignored FQCN, which exercises the matching logic without
     * requiring RN on the classpath. The stub name intentionally differs from the real RN
     * class name; the code path is the same either way.
     */
    private class ReactNativeJavascriptExceptionStub(message: String) : RuntimeException(message)
```

_{Reviews (1): Last reviewed commit: "feat(errortracking): ignoredExceptionTyp..." | Re-trigger Greptile}

[greptile-apps]

When the cause chain is what triggered the skip (not the direct throwable), this log reports the outer wrapper's class name — e.g. java.lang.RuntimeException — even though that class is not in ignoredExceptionTypes. A developer looking at these logs would wonder why RuntimeException was suppressed, since they only configured com.facebook.react.common.JavascriptException. Logging throwable.javaClass.name is only accurate when the outermost exception matched; the message should be phrased to cover the cause-chain case too.

Suggested change

	} else {
	config.logger.log(
	"Skipping autocapture for ignored exception type: ${throwable.javaClass.name}",
	)
	}
	} else {
	config.logger.log(
	"Skipping autocapture: ${throwable.javaClass.name} (or a cause in its chain) matches ignoredExceptionTypes",
	)
	}

Prompt To Fix With AI

This is a comment left during a code review.
Path: posthog/src/main/java/com/posthog/errortracking/PostHogErrorTrackingAutoCaptureIntegration.kt
Line: 88-92

Comment:
When the cause chain is what triggered the skip (not the direct throwable), this log reports the outer wrapper's class name — e.g. `java.lang.RuntimeException` — even though that class is not in `ignoredExceptionTypes`. A developer looking at these logs would wonder why `RuntimeException` was suppressed, since they only configured `com.facebook.react.common.JavascriptException`. Logging `throwable.javaClass.name` is only accurate when the outermost exception matched; the message should be phrased to cover the cause-chain case too.

```suggestion
            } else {
                config.logger.log(
                    "Skipping autocapture: ${throwable.javaClass.name} (or a cause in its chain) matches ignoredExceptionTypes",
                )
            }
```

How can I resolve this? If you propose a fix, please make it concise.

[greptile-apps]

Prefer parameterised tests — the three new tests share identical setup (remoteConfigHolder, isAutocaptureExceptionsEnabled, getDefaultUncaughtExceptionHandler) and verify the same contract with different inputs. At minimum, the "skips capture" (direct match) and "still captures" (no match) cases are a natural @ParameterizedTest pair: the only axes that vary are the throwable type, the ignored-list contents, and whether captureException is expected to be called. Collapsing them reduces boilerplate and makes it immediately clear when a new edge case is added that it's intentionally distinct from existing ones. The cause-chain test is structurally different enough to stay standalone.

Context Used: Do not attempt to comment on incorrect alphabetica... (source)

Prompt To Fix With AI

This is a comment left during a code review.
Path: posthog/src/test/java/com/posthog/errortracking/PostHogErrorTrackingAutoCaptureIntegrationTest.kt
Line: 157-226

Comment:
Prefer parameterised tests — the three new tests share identical setup (`remoteConfigHolder`, `isAutocaptureExceptionsEnabled`, `getDefaultUncaughtExceptionHandler`) and verify the same contract with different inputs. At minimum, the "skips capture" (direct match) and "still captures" (no match) cases are a natural `@ParameterizedTest` pair: the only axes that vary are the throwable type, the ignored-list contents, and whether `captureException` is expected to be called. Collapsing them reduces boilerplate and makes it immediately clear when a new edge case is added that it's intentionally distinct from existing ones. The cause-chain test is structurally different enough to stay standalone.

**Context Used:** Do not attempt to comment on incorrect alphabetica... ([source](https://app.greptile.com/review/custom-context?memory=instruction-0))

How can I resolve this? If you propose a fix, please make it concise.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[greptile-apps]

The comment says "a local class named the same way", but the stub's actual JVM name is com.posthog.errortracking.PostHogErrorTrackingAutoCaptureIntegrationTest$ReactNativeJavascriptExceptionStub — nothing like com.facebook.react.common.JavascriptException. The tests work correctly because they pass ReactNativeJavascriptExceptionStub::class.java.name as the filter value, not the real RN FQCN. The comment should reflect the actual design: a stub with an arbitrary local name, registered under that same local name, so the name-based matching code path is exercised correctly without pulling in the RN dependency.

Suggested change

	/**
	* Local stand-in for `com.facebook.react.common.JavascriptException`. The real type
	* lives in React Native, which isn't (and shouldn't be) a test dependency of the
	* SDK. The ignored-exception filter is purely class-name based, so a local class
	* named the same way exercises the same code path without dragging in RN.
	*/
	private class ReactNativeJavascriptExceptionStub(message: String) : RuntimeException(message)
	/**
	* Local stand-in for `com.facebook.react.common.JavascriptException`. The real type
	* lives in React Native, which isn't (and shouldn't be) a test dependency of the
	* SDK. The ignored-exception filter is purely class-name based: tests register this
	* stub's own JVM name as the ignored FQCN, which exercises the matching logic without
	* requiring RN on the classpath. The stub name intentionally differs from the real RN
	* class name; the code path is the same either way.
	*/
	private class ReactNativeJavascriptExceptionStub(message: String) : RuntimeException(message)

Prompt To Fix With AI

This is a comment left during a code review.
Path: posthog/src/test/java/com/posthog/errortracking/PostHogErrorTrackingAutoCaptureIntegrationTest.kt
Line: 228-234

Comment:
The comment says "a local class named the same way", but the stub's actual JVM name is `com.posthog.errortracking.PostHogErrorTrackingAutoCaptureIntegrationTest$ReactNativeJavascriptExceptionStub` — nothing like `com.facebook.react.common.JavascriptException`. The tests work correctly because they pass `ReactNativeJavascriptExceptionStub::class.java.name` as the filter value, not the real RN FQCN. The comment should reflect the actual design: a stub with an arbitrary local name, registered under that same local name, so the name-based matching code path is exercised correctly without pulling in the RN dependency.

```suggestion
    /**
     * Local stand-in for `com.facebook.react.common.JavascriptException`. The real type
     * lives in React Native, which isn't (and shouldn't be) a test dependency of the
     * SDK. The ignored-exception filter is purely class-name based: tests register this
     * stub's own JVM name as the ignored FQCN, which exercises the matching logic without
     * requiring RN on the classpath. The stub name intentionally differs from the real RN
     * class name; the code path is the same either way.
     */
    private class ReactNativeJavascriptExceptionStub(message: String) : RuntimeException(message)
```

How can I resolve this? If you propose a fix, please make it concise.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[tsushanth]

Thanks @greptile-apps — pushed 7262292 addressing issues 1 and 3.

• Issue 1 (suppress log accuracy): reworded so the log surfaces "the throwable or a cause in its chain" matched — readers won't see a bare RuntimeException reported as suppressed when the ignore list only mentions JavascriptException.
• Issue 3 (test-stub doc comment): restated the actual design (the stub's own JVM name is what tests register as the ignored FQCN, exercising the same code path without dragging RN onto the classpath). The "named the same way" framing was wrong.

Issue 2 (parameterising the new tests): intentionally deferred. The individual test names — skips capture when throwable class is in ignoredExceptionTypes, skips capture when ignored class is anywhere in the cause chain, still captures when throwable class is not in ignoredExceptionTypes — read more clearly under a failure than a @ParameterizedTest table would, and the three cases aren't quite the structural pair Greptile reads them as (the cause-chain case threads cause through a wrapper, the negative case asserts the inverse contract). Happy to collapse to a parameterised form if maintainers prefer it.

All 17 tests still pass after the changes.

[greptile-apps]

Both fixes look correct.

Issue 1: The log now reads ${throwable.javaClass.name} (or a cause in its chain) matches ignoredExceptionTypes — accurate without pinning the message to whichever link in the chain actually matched.

Issue 3: The stub doc comment correctly describes the design: tests register the stub's own JVM name as the ignored FQCN, exercising the name-based matching without pulling RN onto the classpath.

Issue 2 (deferred): The rationale holds. These aren't symmetric variants — the cause-chain test threads cause through a wrapper to exercise a different code path, and the negative test asserts the inverse contract (non-empty ignore list, no match → capture still fires). Collapsing them into a @ParameterizedTest table would obscure those distinctions under a tuple of inputs. The current three-test shape is clearer.

LGTM on 7262292.

Tip: You can customize Greptile's behavior for this repo with .greptile/rules.md and .greptile/config.json.

[marandaneto]

what i'd do differently is to drop after capturing the error, where we do the beforeSend as well
so even if the event is manually captured, its also dropped
right now if you call captureException manually with a suprressed type, its still captured which is a bug

[tsushanth]

Good call — pushed d11c33d restructuring the filter to live at the beforeSend layer per your suggestion.

What moved

• New PostHogIgnoredExceptionTypesBeforeSend (internal) implementing PostHogBeforeSend. It scopes itself to $exception events only, reads $exception_list[*].type from properties, and drops if any entry's type is in errorTrackingConfig.ignoredExceptionTypes. The cause chain is already serialized in $exception_list outer-to-inner by ThrowableCoercer, so walking the list covers the wrapper case (RuntimeException(cause=JavascriptException)) without re-reaching for the original throwable.
• PostHogErrorTrackingAutoCaptureIntegration.install now calls config.addBeforeSend(...) for the new hook (and removeBeforeSend(...) on uninstall), so both autocapture and manual captureException(throwable) callers go through the same drop logic. The isIgnored(throwable) helper that was inside uncaughtException is gone; the handler now always hands off to captureException and the drop decision is the beforeSend's.

Tests

• PostHogIgnoredExceptionTypesBeforeSendTest — 6 cases covering: outer-type match, cause-chain match (wrapped), no-match passthrough, empty ignore list, non-$exception events ignored by the filter, and missing/empty $exception_list passthrough. The wrapped-cause case is the regression equivalent of the old uncaughtException skips capture when ignored class is anywhere in the cause chain test, now at the right layer.
• PostHogErrorTrackingAutoCaptureIntegrationTest — replaced the three old uncaughtException skips capture … tests with two new ones: one asserts addBeforeSend / removeBeforeSend are called with a PostHogIgnoredExceptionTypesBeforeSend instance on install / uninstall, the other asserts the handler always calls captureException regardless of the throwable's class. The drop semantics now live in the beforeSend's own unit tests.

Full posthog module suite passes locally: ./gradlew :posthog:test --tests "com.posthog.errortracking.*" → 22 tests, 0 failures.

(The greptile "non-parameterised tests" P2 from the earlier review still applies to the BeforeSend tests by the same argument, but they're shaped distinctly enough — different inputs assert different invariants, not the same one with different values — that I'd default to leaving them. Easy to collapse if you'd prefer.)

[marandaneto]

that wont work, types might be minified/not available, we have to match the type with the instance type

[ioannisj]

I think I agree with @marandaneto on this, string matching will probably not work because of minification. So this should probably take a Class not a String and check via isInstance. This means that we can't use beforeSend to run these checks.

I believe we can drop from

posthog-android/posthog/src/main/java/com/posthog/PostHog.kt

Line 646 in 3ca38b1

override fun captureException(

which is called for both manual and automatic error captures

we'll want to keep the cause-chain walk too cause we'll need that for PostHogThrowable

[tsushanth]

Thanks @marandaneto and @ioannisj. Refactored to take MutableList<Class<out Throwable>> instead of List<String> and moved the check into PostHog.captureException so both autocapture and direct callers go through it, exactly as suggested. Matching is by Class.isInstance so R8 / ProGuard renaming can't silently break the filter, and the cause-chain walk is preserved (bounded by MAX_CAUSE_DEPTH = 32 to guard against cyclic chains) so the PostHogThrowable wrapper from the uncaught handler still surfaces the underlying type.

PostHogIgnoredExceptionTypesBeforeSend is gone (and so is its register/unregister wiring on the autocapture integration); the two BeforeSend-shaped tests under PostHogErrorTrackingAutoCaptureIntegrationTest are replaced by three tests on PostHogTest covering the direct-match drop, the cause-chain drop, and the keep-when-not-matching path. 696 tests pass under ./gradlew :posthog:test; spotless and apiDump are up to date.

Ready for another look whenever you have a moment.

[ioannisj]

Thanx @tsushanth, this is almost there. Left some last few comments + some merge conflicts to resolve

[ioannisj]

Let's move this inside try-catch below?

[ioannisj]

Let's remove reference in public docs and move to header attribution if indeed necessary

[ioannisj]

Lets not edit changelog directly but provide a changeset entry. Refer to RELEASING.md

[ioannisj]

Let's simplify this a little but, too chatty

[tsushanth]

Thanks @ioannisj. Squashed the branch onto current main (so the diff is now scoped to the 5 files this PR actually owns), addressed all four review threads:

• moved the ignoredExceptionTypes check inside captureException's existing try block (4abc99f)
• removed the React Native reference from the public docstring on errorTrackingConfig.ignoredExceptionTypes and tightened the doc to the essentials
• dropped the direct posthog/CHANGELOG.md edit and added .changeset/error-tracking-ignored-exception-types.md per RELEASING.md
• PostHogErrorTrackingAutoCaptureIntegration now sits unchanged on top of main — no comment churn there either

706 tests pass under ./gradlew :posthog:test; make checkFormat and apiDump are up to date. Ready for another pass whenever.

[ioannisj]

These tests should not be removed here

[ioannisj]

Same, probably stale commits from main

[ioannisj]

https://github.com/PostHog/posthog-android/pull/569/changes#r3459559560

[ioannisj]

Need to rebase on main to remove some unrelated changes (e.g exceptionSteps + tests). Left a comment, not a blocker since this does not sit directly on RN path/case but the config option would be more complete if we gated generic capture() method as well

[ioannisj]

Now that we have the concrete types, I think it should be possible to also gate the generic capture("$exception") path as well