Client-server telemetry correlation broken: browser and API report different operation ids in App Insights

[RodriSanchez1]

Problem

Browser dependencies and API requests for the same HTTP call appear in Application Insights under different operation_Ids, so the end-to-end transaction view cannot link them. Investigating a user-reported stale-data issue required manually correlating client and server telemetry by timestamp and URL.

Root cause

Two independent gaps:

1. The web app excludes *.cboard.io in correlationHeaderExcludedDomains (cboard-org/cboard@5ea5084), so the JS SDK never sends the traceparent/Request-Id headers to api.app.cboard.io. Without them, the Node SDK generates a fresh operation_Id per request instead of adopting the browser's. The wildcard was introduced to fix a Chrome CORS error with cbuilder.cboard.io (cboard-org/cboard@837c09b), but it unintentionally swallowed the API domain too. The API itself was never the offender: its cors middleware sets no allowedHeaders, so preflights reflect the requested headers and traceparent is already allowed.

2. The API does not list Request-Context in Access-Control-Expose-Headers, so the browser SDK cannot read the server's appId from responses and the Application Map shows the API as an unmonitored external dependency instead of the "Cboard API" component.

Fix

• This repo: add exposedHeaders: ['Request-Context'] to the cors configuration.
• cboard-org/cboard (follow-up): revert the exclusion wildcard *.cboard.io back to cbuilder.cboard.io so correlation headers flow to the API again, keeping cbuilder excluded (its server rejects traceparent preflights).

Verification

After both changes are deployed (QA first), a browser dependency and its server request should share one operation_Id:

union requests, dependencies
| where timestamp > ago(1h)
| summarize dcount(itemType) by operation_Id
| where dcount_itemType > 1