[NR-485061] Send MobileJSError to new Endpoint

[ywang-nr]

Tickets:

1. https://new-relic.atlassian.net/browse/NR-485061
2. https://new-relic.atlassian.net/browse/NR-521092
3. https://new-relic.atlassian.net/browse/NR-485065
4. https://new-relic.atlassian.net/browse/NR-535222

What's changed:

1. Send MobileJSError to new endpoint
2. Save MobileJSError in memory and files as backup

[ndesai-newrelic]

@ywang-nr

Critical Issues

1. Race condition on jsErrorPayloadString (file I/O + volatile field)
   JSErrorDataController.java:36 — jsErrorPayloadString is volatile but the read-modify-write cycle in sendJSErrorData is not atomic. Multiple concurrent calls can:

• Read the same cache file simultaneously
• Overwrite each other's events in jsErrorPayloadString
• Lose JS error events

The file read at line 64-77 and the write at line 86-87 are unsynchronized. If two JS errors arrive concurrently, one will clobber the other. Consider synchronizing sendJSErrorData or using a lock
around the read-update-write cycle.

2. NPE in sendJSErrorData when reporter is null
   JSErrorDataController.java:54-57 — JSErrorDataReporter.getInstance() can return null (before initialization or after shutdown), yet line 57 dereferences jsErrorReporter.payloadStore without a null
   check. This will crash.

3. NPE in getStoredJSErrorData / deleteCacheFile
   Same pattern at lines 116 and 137 — getInstance() return value is dereferenced without null guard.

4. onHarvestConnected assigns null to volatile field
   JSErrorDataReporter.java:199 — getStoredJSErrorData() can return null, which gets assigned to jsErrorPayloadString. Then in onHarvest() line 207, the != null check passes through to isEmpty() — OK, but
   the field was initialized as "", so assigning null breaks the invariant. Downstream code that relies on non-null will break.

---

Performance Concerns

5. Synchronous file I/O on caller thread
   JSErrorDataController.sendJSErrorData reads the cache file synchronously (lines 65-77) on whatever thread the caller is on. If called from the main thread, this blocks the UI. The write is correctly
   offloaded via PayloadController.submitCallable, but the read is not.

6. Redundant JSON serialization in every harvest cycle
   onHarvest() at line 207-214 converts the entire jsErrorPayloadString to bytes, wraps it in a Payload, stores it, then sends it — every harvest cycle, even if no new errors arrived since the last
   harvest. The onHarvestComplete then deletes the cache and clears the string, but if onHarvest fires before a new error comes in, it will re-send the same data.

---

Lifecycle Safety

7. JSErrorDataReporter is never shut down
   PayloadController calls JSErrorDataReporter.initialize() and start() but there's no corresponding shutdown() call in PayloadController.shutdown(). The AgentDataReporter has the same pattern, but the
   new reporter adds harvest listeners (onHarvest, onHarvestComplete, onHarvestConnected) that will keep firing after the reporter should be dead.

8 . Shared PayloadStore between AgentDataReporter and JSErrorDataReporter
Both reporters get agentConfiguration.getPayloadStore() — they share the same store. reportCachedJSErrorData() iterates payloadStore.fetchAll() which returns HEX payloads too. The JSError reporter will
try to send HEX payloads as JSON to the /mobile/errors endpoint, and vice versa.

---