Release Notes

Version 1.1.0

📅 Release Date

August 8, 2026

📖 Overview

One addition. A Worker can now keep its successful requests out of Analytics Engine without keeping its own copy of the logging middleware, through the same configure/resolve path every other setting travels.

Before this, a deployment that only wanted its failures had to fork logToAnalytics and inline the condition. Two Workers had done exactly that, with the same condition, which is the signal that the setting was missing rather than the middleware being wrong.

⚠️ Breaking Changes

• AnalyticsSettings gains a required member. Anything constructing that shape by hand rather than spreading cloudflareDefaults will stop type-checking until it supplies minRequestStatus. Overrides are partial, so a deployment naming only binding or only enabled is unaffected too. In practice the compile error is confined to test fixtures that assemble a literal, which is why this lands as a minor.

Runtime behaviour is unchanged for anyone who does not set the new field. Requests are still recorded at every status, event() still records unconditionally, and an unbound TELEMETRY dataset still drops the point rather than throwing.

🚀 Features

• analytics.minRequestStatus: a threshold below which a request measurement is not recorded.

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

No new exported name: minRequestStatus is a member on an interface the entry point already published. Both exports subpaths are unchanged, and so is the count of names behind them.

🔧 Enhancements

• The default records everything, which is the behaviour before this change:

  analytics: {
    binding: 'TELEMETRY',
    enabled: true,
    minRequestStatus: 0
  }
  

  It stays the default because the trade-off belongs to the deployment rather than to this package: a dataset holding only failures cannot answer request rate or latency percentiles, because the denominator is no longer in it. Raise the threshold when nobody queries the successes, and know that the rate goes with them.

• The check lives in AnalyticsService.request, not in logToAnalytics. It is a telemetry policy, not a delivery one — any caller recording a request measurement should get the same answer, including one that never registers the Hono middleware at all. Putting it in the middleware would mean a Worker calling request() directly silently kept behaviour the setting says it turned off.

• event() is deliberately unaffected. A threshold over response status has nothing to say about a domain metric, which is not describing a response, so raising minRequestStatus to 400 still records every event() a caller writes by hand. The spec pins that, because it is the part most likely to be "fixed" later by someone applying the guard uniformly.

• The kernel moves with it. @bayudwiyansatria/core goes to ^1.1.0, which brings DeliverySettings — timeout, retries, backoff, and a user agent for outbound calls. Nothing in this package reads it. The bump keeps the pair in step, so a Worker spreading both defaults gets delivery in its configuration surface and can override it like any other module.

🐛 Bug Fixes

• None.

🔐 Security

• None.

🧪 Tests

npm run lint, npm run test:run, and npm run build all clean. 57 specs across five suites, up from 47 across four: test/core/services/AnalyticsService.spec.ts is new and carries all ten.

One note for anyone extending that spec. lazySettings memoises on first read — right for a Worker that configures once at startup, fatal to a test file that wants two thresholds — so each case builds its service after jest.resetModules() and re-imports both packages. Configure one registry while the service reads another and every assertion passes for the wrong reason.

📚 Documentation

• None.

⬆️ Upgrading

npm install @bayudwiyansatria/cloudflare@1.1.0 @bayudwiyansatria/core@1.1.0

If you spread cloudflareDefaults into configure(), there is nothing to do — telemetry behaves exactly as it did.

To record only failures:

configure({ ...systemDefaults, ...cloudflareDefaults }, { analytics: { minRequestStatus: 400 } })

Per-field merge applies as everywhere else, so naming minRequestStatus keeps the default binding and enabled. If you fork logToAnalytics to filter by status today, delete the condition and set this instead.

🚨 Known Issues

• None

📦 Dependencies

👥 Contributors

• Bayu Dwiyan Satria

🙏 Acknowledgments

Thanks to the maintainers of the two Workers whose identical forks of logToAnalytics are what surfaced the missing setting.

For more information, visit the project's GitHub repository.