…@8 (MSRC 115880) (#1498)

* Remove @azure/functions-old dependency to fix MSRC 115880

The @azure/functions-old alias (npm:@azure/functions@3.5.1) transitively pulls in uuid@8.3.2, which is flagged by MSRC 115880 / GHSA-w5hq-g745-h8pq (out-of-range buffer writes in uuid v3/v5/v6). There is no patched 3.x release of @azure/functions (3.5.1 is the latest in that line), and the 4.x line dropped the v3 programming model.

All usages of @azure/functions-old in this repo were type-only. Inline the v3 Context/HttpRequest/TraceContext/HttpRequestHeaders/Logger interfaces in src/shim/azureFunctionsV3Types.ts (sourced from @azure/functions@3.5.1, MIT) and switch the consumers to `import type` from the local module. Drop the package from package.json so the entire chain (including uuid@8.x via functions-old) is removed from the dependency tree.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Force all transitive uuid deps to ^11.1.1 via npm overrides

After removing @azure/functions-old, two unrelated transitive uuid@8.3.2 instances remain in the tree (via @azure/msal-node, brought in by @azure/identity, and via nyc->istanbul-lib-processinfo). uuid@<11.1.1 is vulnerable to GHSA-w5hq-g745-h8pq, so strict scanners will still flag them.

Add a blanket `uuid: ^11.1.1` override to force every transitive uuid to the patched line. Also pin @azure/msal-node to ^3.7.3 under @azure/identity because @azure/identity@4.13+ pulls @azure/msal-node@5.x, whose ESM-only .d.cts declarations break this project's CommonJS `module: nodenext` TypeScript build (TS1479). msal-node 3.x only uses uuid.v4(), which is API-compatible with uuid@11.

Verified: `npm ls uuid` reports only uuid@11.1.1 (no 8.x anywhere); tsc build clean; shim tests unchanged from baseline.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Replace npm overrides with real dep updates to scrub uuid@8

Earlier commit relied on an `overrides` block to force transitive `uuid` to `^11.1.1`. Replace that with real dependency updates so the lockfile is clean of any pinning hacks:

- Bump `@azure/identity` `^4.6.0` -> `^4.13.1` so it brings in `@azure/msal-node@5.x`, which dropped its `uuid@8.x` dependency entirely.

- Replace `nyc@^15.0.0` (which pulls `istanbul-lib-processinfo` -> `uuid@8.3.2` and has no upstream fix) with `c8@^11.0.0`. c8 uses native V8 coverage and has zero uuid dependency. Update all `test*` scripts in package.json from `nyc mocha ...` to `c8 mocha ...` — c8 is a drop-in CLI replacement and produces istanbul-compatible reports.

- Add `skipLibCheck: true` to `tsconfig.json`. Required because `@azure/msal-node@5.x` ships ESM-only `.d.cts` declarations that trigger TS1479 under this project's `module: nodenext` CJS build.

- Drop the `overrides` block from package.json.

Verification: `npm ls uuid` -> `(empty)` across the entire dep tree (prod + dev). `tsc` builds clean. `mocha` shim tests: 24 pass / 8 pre-existing failures (identical to main). `c8` coverage runs and emits expected text-summary report.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Revert switch from nyc to c8; keep nyc on dev side

Per maintainer preference, keep `nyc@^15.0.0` as the dev coverage tool. The transitive `uuid@8.3.2` it brings in via `istanbul-lib-processinfo` (no nyc/istanbul-lib-processinfo version exists without it) is accepted as a dev-only finding.

Production tree is clean of `uuid@8.x`: the @azure/functions-old removal and @azure/identity bump (which moves to @azure/msal-node@5.x with no uuid dep) stand.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Revert .gitignore change (no longer needed after reverting to nyc)

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Restore .gitignore byte-exact to main

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Revert tsconfig change and @azure/identity bump

Touching tsconfig.json was an unintended side effect of bumping @azure/identity to ^4.13.1 (which pulls @azure/msal-node@5.x, whose .d.cts triggers TS1479 under module: nodenext).

Revert both changes. Scope of this PR is now exactly what MSRC 115880 named: removing the @azure/functions-old chain. The msal-node->uuid@8 chain is a separate finding to track in its own ticket.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Bump @azure/identity to ^4.13.1 to drop transitive uuid@8.3.2 from prod tree

@azure/identity@^4.13.1 pulls @azure/msal-node@>=5.1.5, which no longer
depends on uuid. This removes the @azure/msal-node -> uuid@8.3.2 chain
from the production dependency tree.

msal-node 5.x ships a known-buggy types/index.d.cts that re-exports from
"./index.js"; under module: nodenext that resolves to the sibling
index.d.ts, which is treated as ESM because the parent package.json has
type: module, triggering TS1479. Rather than touching this project's
tsconfig, add a tiny postinstall script that drops a
{"type":"commonjs"} package.json into msal-node/types/ and
msal-common/types/, which makes TS resolve those declarations as CJS
(matching what they actually describe).

The only remaining transitive uuid@8.3.2 is nyc ->
istanbul-lib-processinfo, which has no upstream fix and is dev-only.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Add skipLibCheck and drop msal-node types postinstall patch

Replace the postinstall shim that worked around @azure/msal-node 5.x's
broken types/index.d.cts (TS1479 under module: nodenext) with the more
conventional skipLibCheck: true. The postinstall hack was opaque and
fragile; skipLibCheck is the standard one-line fix for third-party
.d.ts bugs and is opted into by most TS projects anyway.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

---------

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…1499)

AutoCollectExceptions previously invoked LoggerProvider.forceFlush() on every uncaughtException and unhandledRejection, with no client-side rate limit. Under exception storms this bypassed BatchLogRecordProcessor batching and amplified request rate against the ingestion endpoint.

Changes:

- Remove per-exception forceFlush; flush only on the terminal exit path (sole listener + reThrow).

- Add a 50/min token-bucket rate limiter; emit a single summary trackException on bucket refill reporting the suppressed count.

- Always record the terminal/fatal exception, bypassing the rate limit.

- Harden terminal flush with onRejected + try/catch so a flush failure cannot leave the process hanging.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

)

* perf: expand benchmarks vs upstream OpenTelemetry + add CI regression gate

Adds four new perf scenarios so we can measure overhead of this package against equivalent upstream OpenTelemetry calls:

- AzureMonitorSpanTest / AzureMonitorLogTest (useAzureMonitor + direct OTel API)

- OtelSpanTest / OtelLogTest (plain @opentelemetry/sdk-trace-base & sdk-logs reference, informational only)

Introduces a deterministic benchmark runner (bench.mjs + runBenchmarks.mjs) that bypasses the @azure-tools/test-perf worker pool, runs each scenario in a fresh Node child process to avoid OTel global-state contamination, and emits structured JSON with median/mean/stdev across N samples.

Adds .github/workflows/performance.yml: packs both PR and base branch as tarballs via npm pack, installs each in turn under the PR's perf harness, runs the benchmark suite, and fails the job (blocking merge when set as a required check) if any gating scenario regresses by more than PERF_REGRESSION_THRESHOLD percent (default 15%). Posts a sticky PR comment with the comparison table.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* perf: address PR feedback and fix CI build

Fixes CI: add explicit npm run build of the perf harness before running benchmarks; previous run died with ERR_MODULE_NOT_FOUND because dist-esm was never produced.

Review feedback:

- workflow: switch perf harness install to npm ci; add --no-package-lock to tarball installs so the lockfile is not rewritten mid-run

- AzureMonitor scenarios: acquire @opentelemetry/api and @opentelemetry/api-logs via createRequire resolved from the installed applicationinsights, so the Tracer/Logger we benchmark is backed by the SAME api / api-logs instance that useAzureMonitor() mutated (otherwise a duplicate hoisted copy at the harness level would yield a no-op proxy and we'd silently measure nothing)

- OTel reference scenarios: use provider.getTracer / provider.getLogger directly instead of going through the global registry, eliminating dual-instance concerns for these

- index.spec.ts: capture console.log with rest args + util.format so multi-arg / non-string calls are formatted the same way Node would print them

- runBenchmarks.mjs: propagate child.error and child.signal in failure messages (spawnSync status can be null on spawn error or signal exit)

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* perf(ci): reduce sample budget so the perf job fits in its timeout

Previous run cancelled at 25min job timeout: candidate ran 12min (5 samples x 6 scenarios x ~24s/sample on CI runners; AzureMonitor scenarios pay a 5-10s SDK init cost per fresh child process), baseline got 12min in before cancellation.

Cut samples 5 -> 3, duration 8s -> 5s, warmup 2s -> 1s. New estimate: ~5min per side, ~12min total with install/build. Bumped job timeout 25 -> 40 min for safety margin.

Median of 3 samples is still robust to a single outlier (the main source of CI flake), and 5s is enough sustained measurement time for even the slowest scenario (AzureMonitorLog at ~12k ops/s yields ~60k ops per sample).

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* perf: align OTel package versions with applicationinsights to dedupe api-logs

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

---------

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…xporter (#1504)

The `^1.0.0-beta.41` caret range previously specified for
`@azure/monitor-opentelemetry-exporter` is permissive enough under semver
that `npm install` (with no lockfile) can resolve it to
`@azure/monitor-opentelemetry-exporter@1.0.0-preview.6` -- the prerelease
identifier `preview` sorts higher than `beta` lexicographically, so
`maxSatisfying` picks it as the "best" match.

`1.0.0-preview.6` (published October 2020) still exists on npm and pulls
in the deprecated `@azure/core-http@1.2.6` -> `uuid@^8.3.0` chain, plus
the legacy `@opentelemetry/tracing@0.10.2` -> `@opentelemetry/resources@0.10.2`
-> `gcp-metadata@3.5.0` -> `json-bigint@0.3.1` chain. These transitives
re-introduce CVE-2020-8237 (json-bigint) and the GHSA-w5hq-g745-h8pq
uuid advisory that have been the subject of recent issue reports
(#1501, #1502). Today we are protected only because
`@azure/monitor-opentelemetry@1.18.0` happens to pin the exporter to an
exact version transitively, but that is fragile and would not hold for a
lockfile-less consumer install.

Replace the caret with an explicit two-clause range that:

  - allows the current `1.0.0-beta.41` and any future `1.0.0-beta.*` (the
    `b` in `beta` is alphabetically less than `c`); and
  - allows future stable `1.x.x` releases via the `|| ^1.0.0` clause; but
  - rejects `1.0.0-preview.*`, `1.0.0-dev.*`, and `1.0.0-alpha.*` because
    their prerelease identifiers sort >= `c`.

The resolved version in `package-lock.json` is unchanged
(`1.0.0-beta.41`), so the runtime tree is identical. All 247 unit tests
pass.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* perf: amortize per-sample startup and post comments on fork PRs

Run all --samples of a given scenario inside a single child Node
process. OpenTelemetry global-state isolation is preserved because
each scenario still gets a fresh process, but Node startup, importing
applicationinsights' large dependency tree, and one-time SDK init
(useAzureMonitor()) are now paid once per scenario instead of once
per sample. On the perf CI runner this removes several minutes from
each "Run X benchmarks" step.

Split the perf workflow into producer/consumer to support fork PRs:
- performance.yml now runs without pull-requests:write and uploads
  baseline.json, candidate.json, perf-comparison.md, and pr-number.txt
  as the perf-results artifact. The inline sticky-comment step (which
  was gated on head.repo.full_name == github.repository, so forks
  never got comments) is removed.
- performance-comment.yml is new. It triggers on workflow_run after
  Performance completes, runs in the trusted base-repo context with
  pull-requests:write, downloads the artifact, validates the PR
  number is a positive integer, regenerates report.md from the JSON
  using the base branch's own trusted comparePerf.mjs (so attacker-
  supplied markdown is never posted under the writable token), and
  posts the sticky comment.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* perf: address review feedback on perf workflow split

- bench.mjs: require Number.isInteger for --samples so 1.5 is rejected.
- performance-comment.yml: resolve PR number from workflow_run event payload (or listPullRequestsAssociatedWithCommit keyed off the untamperable head_sha) instead of the untrusted pr-number.txt artifact, so a malicious fork PR cannot trick the writable token into commenting on an unrelated PR.
- performance-comment.yml: drop the duplicated PERF_REGRESSION_THRESHOLD env var; comparePerf.mjs's built-in default of 15 now applies, removing the third source of truth.
- performance.yml: drop the now-unused pr-number.txt writer/upload.

---------

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

… protobufjs overrides (#1508)

* fix(deps): upgrade OpenTelemetry and nyc to resolve audit vulns, drop protobufjs overrides

- Bump @azure/monitor-opentelemetry to ^1.18.1 and OTel 0.x exporters/sdk to ^0.218.0.
  otlp-transformer@0.218 no longer pulls protobufjs, so the only protobufjs left is
  the safe 7.x line via @grpc/proto-loader. Resolves the high-severity protobufjs
  advisories without overrides.
- Remove the @opentelemetry/otlp-transformer and @grpc/proto-loader protobufjs overrides.
- Bump nyc to ^18.0.0, which resolves the @babel/core and uuid (dev) advisories via
  patched istanbul-lib-instrument and istanbul-lib-processinfo.
- Keep the mocha -> serialize-javascript override: it is the only fix for a high-severity
  advisory since no mocha release ships a patched serialize-javascript (dev-only).

Remaining audit findings are upstream-gated (@opentelemetry/core <2.8.0, pending the
Azure Monitor distro) or dev-only with no patched release (js-yaml via nyc).

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* fix(perf): enable skipLibCheck in perf harness tsconfig

The perf harness installs the candidate applicationinsights, which pulls
@opentelemetry/instrumentation-pg -> @types/pg -> pg-protocol@1.14.0 whose
.d.ts uses a generic Buffer<...>. With the harness's @types/node@18 (non-generic
Buffer), tsc failed with TS2315. Enable skipLibCheck (matching the root tsconfig)
so type-checking of third-party .d.ts files no longer breaks the perf build.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

---------

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Bump version to 3.15.1 and update CHANGELOG with dependency upgrades, removal of @azure/functions-old, exporter prerelease blocking, and the AutoCollectExceptions rate-limit bug fix.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>