fix: three v0.2.0 gaps — partial span flush, intake exclusion by origin, crash faulting address

[Fiona2016]

Three independent fixes, one commit each. They share no code and can be reverted separately.

Opened as a new PR: #11 was already merged into publish when this work started, so there was nothing to append to. This branch is cut from publish and contains #11.

1. Export a finished span without waiting for its trace siblings

src/entries/instrument.ts — flushMinSpans: 1.

RUM resource events are derived from the spans dd-trace exports, and dd-trace exports a trace only once every span in it has finished — or once flushMinSpans have, a threshold defaulting to 1000 that a desktop app never reaches. A single request that never returned therefore withheld the resource events of every other request made from the same ipcMain.handle invocation, for the rest of the process' life.

Attribution does not move: a resource event is placed by its own span's start time, not the trace's.

Verified in a real Electron app, not only in Node. New scenario: two requests from one IPC handler, one to an endpoint that never answers.

	resource event for the completed request
before	never arrives (10s timeout)
after	arrives, status_code: 200, correct URL

No loss and no duplication elsewhere: the three single-request scenarios still assert exactly one resource event each, with _dd.trace_id / _dd.span_id intact.

2. Exclude the SDK's own uploads by origin, before they are instrumented

isIntakeRequest() compared hostnames, which is wrong in both directions:

• with proxy set, its port was dropped, so every application request sharing the proxy's host was discarded whatever its port — the normal shape of a self-hosted deployment;
• with no proxy and a site carrying a port (rum.example.internal:8443, a valid configuration), the stored value kept the port while new URL(url).hostname never has one, so the comparison matched nothing and the SDK reported its own uploads as resources — which produced further uploads.

It also matched on span.resource, which dd-trace sets to the HTTP method for client spans, so that branch could only ever produce false positives. It is gone.

Both directions are fixed by comparing origins (computeIntakeHostname → computeIntakeOrigin), and the exclusion moves to where every other FlashCat SDK puts it. On iOS, Android and HarmonyOS the uploader is simply not part of what gets instrumented; Electron was the only one filtering after the fact, at export time. Tracing now hands dd-trace a blocklist for the intake origin, applied by HttpClientPlugin before a span is recorded — and all three span-producing paths (node:http, global fetch, Electron net.request) derive from it. SpanProcessor keeps a corrected check as a second line of defense.

The e2e harness could not see any of this: it pointed the intake at localhost while the test server answered on 127.0.0.1, so the two never collided as hostnames and a host-only exclusion passed every scenario. Both now use 127.0.0.1 and differ only by port.

Mutation-verified, in a real Electron app:

• revert the fix → 5 of the 6 resource scenarios fail (every application request disappears);
• disable the export-time check and keep only the blocklist → all 6 still pass, so the structural layer carries the exclusion on its own, across all three HTTP paths.

3. Report the faulting address of a native crash — and why the unknown 0x… type is not a bug

Verified in a real Electron app on macOS before changing anything. process.crash() writes through a null pointer, Crashpad records the Mach exception, and the report reads EXC_BAD_ACCESS / KERN_INVALID_ADDRESS with address 0x0. The processor's exception mapping works; no fix was needed.

unknown 0x00000000 / 0x00000000 is the fallback for a minidump carrying no exception record — a property of how the process died, not a gap in the SDK. Probing the same app with signals delivered by kill() (SIGSEGV, SIGABRT, SIGILL, SIGFPE) produced exactly that string every time, on macOS. So the sole change here is additive: the faulting address, which the processor had always resolved and the SDK dropped, now goes to error.meta.exception_codes — that field rather than a name of our own because the intake decodes error.meta into a fixed set of fields and drops the rest. It is the only lead left precisely when the type has no name. No signal-name table of our own.

crash.scenario.ts now asserts the type is a real name and the address is present; both fail if the address is dropped.

Verification

	before	after
yarn test:unit	600	616
yarn test:e2e	37	39
yarn test:integration	24	24

yarn typecheck, yarn test:e2e:typecheck and yarn format:check clean. yarn lint reports the same 2 pre-existing errors as publish, in files this branch does not touch.

Every behavior change has a guard proven to fail without it — see each section above.