2026-08-08 — analytics.minRequestStatus

AnalyticsService.request gains a threshold, so a Worker can keep the successful requests out of Analytics Engine without keeping its own copy of the logging middleware.

What was added

// Only failures leave a data point.
configure(defaults, { analytics: { minRequestStatus: 400 } })

Default 0, which records every request — the behaviour before this change, and what rate and latency queries need.

The check lives in AnalyticsService.request, not in logToAnalytics, because it is a telemetry policy rather than a middleware one: any caller recording a request measurement should get the same answer. event() is deliberately unaffected — a domain metric is not describing a response, so a threshold over response status has nothing to say about it.

Why

Two Workers had independently forked logToAnalytics to add exactly this condition. Both are reached almost entirely over service bindings, both succeed almost always, and the successes were crowding out the failures anyone actually queries for. Two identical forks of a middleware is the signal that the middleware was missing a setting.

The trade-off belongs to the deployment, not to this package, which is why the default does not change: a dataset holding only failures cannot answer request rate or latency percentiles, because the denominator is not in it. The setting's own documentation says so.

Tests

test/core/services/AnalyticsService.spec.ts is new — ten cases over the default threshold, a raised one, and telemetry switched off entirely. Worth noting for anyone extending it: lazySettings memoises on first read, which is correct in a Worker that configures once at startup and fatal to a test file wanting two thresholds, so each case builds its service after jest.resetModules() and re-imports both packages. Configure one registry and read another and every assertion passes for the wrong reason.

Released as 1.1.0, and it takes @bayudwiyansatria/core ^1.1.0 with it.