fix(analytics-browser): prevent infinite Amplitude network requests

[daniel-graham-amplitude]

Summary

If network tracking is configured to include amplitude.com and allows status code 200, then it can cause infinite network request calls because it would trigger an Amplitude event, and then that would trigger a network request callback, which would trigger an Amplitude event...

This checks the events, and if it contains '[Amplitude] Network Request' as an event_type, then do not track it

Checklist

• Does your PR title have the correct title format?
• Does your PR have a breaking change?: No

[Copilot]

Pull Request Overview

This PR prevents infinite loops in Amplitude network tracking by filtering out events that represent Amplitude’s own “[Amplitude] Network Request” calls. Key changes include:

• Adding manual browser test pages for XHR/Axios and Fetch scenarios.
• Extending shouldTrackNetworkEvent with a new isAmplitudeNetworkRequestEvent check and related tests.
• Adjusting core types and exports to support the new request‐type and wrapper interfaces.

Reviewed Changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
test-server/browser-sdk/xhr.html	New manual test suite for XHR/Axios network tracking, including abort and various payload types
test-server/browser-sdk/fetch.html	New manual test suite for Fetch network tracking with similar scenarios
packages/plugin-network-capture-browser/src/track-network-event.ts	Implements amplitude‐loop detection via isAmplitudeNetworkRequestEvent and skips those events
packages/plugin-network-capture-browser/test/autocapture-plugin/track-network-event.test.ts	Adds unit tests covering the new skip logic for “[Amplitude] Network Request” and URL‐missing cases
packages/analytics-core/src/types/browser-config.ts	Updates networkTracking description to reflect detailed options
packages/analytics-core/src/index.ts	Reorders exports to expose NetworkRequestEvent from the public API
packages/analytics-core/src/network-request-event.ts	Introduces safe request/response wrappers and updated event serialization
packages/analytics-core/src/network-observer.ts	Refactors fetch/XHR observers to use the new wrappers and centralized handling logic

Comments suppressed due to low confidence (1)

packages/plugin-network-capture-browser/test/autocapture-plugin/track-network-event.test.ts:284

• [nitpick] Consider adding an end-to-end test for trackNetworkEvents itself to verify that requests flagged by shouldTrackNetworkEvent (e.g., Amplitude loop events) are actually filtered out in the emitted analytics stream.

test('network request body contains "[Amplitude] Network Request"', () => {

[Copilot]

[nitpick] Avoid deep-importing from internal paths (lib/esm/...). Instead, import IRequestWrapper from the public package entry point to reduce brittleness.

Suggested change

	import { IRequestWrapper } from '@amplitude/analytics-core/lib/esm/network-request-event';
	import { IRequestWrapper } from '@amplitude/analytics-core';

[Copilot]

[nitpick] The name parseUrl suggests returning a standard URL object but actually returns a custom result. Consider renaming to extractUrlComponents or explicitly typing the return to improve clarity.

Suggested change

	function parseUrl(url: string | undefined) {
	interface UrlComponents {
	query: string;
	fragment: string;
	href: string;
	hrefWithoutQueryOrHash: string;
	host: string;
	}
	function extractUrlComponents(url: string | undefined): UrlComponents | undefined {

[promptless]

✅ No documentation updates required.

[Mercy811]

Should we ignore all requests to amplitude http v2 endpoint?

[daniel-graham-amplitude]

Should we ignore all requests to amplitude http v2 endpoint?

I think just requests that have [Amplitude] Network Request in their response. It's still useful for us, especially internally, to find errors from those endpoints.