[Feat] [SDK-399] Capture logcat output as telemetry events #369
Claude / Claude Code Review
completed
May 1, 2026 in 19m 49s
Code review found 2 potential issues
Found 4 candidates, confirmed 2. See review comments for details.
Details
| Severity | Count |
|---|---|
| 🔴 Important | 0 |
| 🟡 Nit | 2 |
| 🟣 Pre-existing | 0 |
| Severity | File:Line | Issue |
|---|---|---|
| 🟡 Nit | rollbar-android/src/main/java/com/rollbar/android/LogcatTelemetryCapture.java:127-129 |
selfTag exact-match filter leaks Rollbar-internal logs into telemetry |
| 🟡 Nit | rollbar-android/src/main/java/com/rollbar/android/AndroidConfiguration.java:67-76 |
Stale javadoc: 'manual telemetry events' no longer matches LOG implementation |
Annotations
claude / Claude Code Review
selfTag exact-match filter leaks Rollbar-internal logs into telemetry
**Nit:** the `selfTag` filter at `LogcatTelemetryCapture.processLine()` (line 127) only excludes lines whose tag exactly equals `"Rollbar"`, but `ConnectivityDetector.java:49` logs with tag `com.rollbar.android.notifier.sender.ConnectivityDetector` (from `getCanonicalName()`), which slips through and gets captured as user telemetry when `captureLogsAsTelemetry` is enabled. Impact is small (a single one-shot warning, only when `ACCESS_NETWORK_STATE` is missing AND `suspendWhenNetworkIsUnavailable
claude / Claude Code Review
Stale javadoc: 'manual telemetry events' no longer matches LOG implementation
The javadoc on `AndroidConfiguration.Builder.captureLogsAsTelemetry` (lines 67-76) still describes captured logs as being recorded as 'manual telemetry events', but the implementation in `LogcatTelemetryCapture.processLine()` calls `tracker.recordLogEventFor(...)` which produces `TelemetryType.LOG` events. This misleads consumers about which telemetry type to filter on in the Rollbar UI; replace 'manual telemetry events' with 'log telemetry events' (or 'telemetry events of type LOG').
Loading