Release Notes

Version 1.2.2

📅 Release Date

August 29, 2026

📖 Overview

One value moves. cloudflareDefaults.analytics.minRequestStatus goes from 0 to 500, so a data point is a failure unless a Worker says otherwise.

1.1.0 added the setting and deliberately left the default at 0, on the reasoning that the trade-off belonged to the deployment rather than to this package. Three weeks of production use say deployments do not exercise a choice they cannot see they are making. Across the Workers binding an Analytics Engine dataset, a quarter had set the threshold — and they were the ones whose forked middleware had motivated the setting in the first place. The rest were recording every 200.

Of the ones that had not, exactly one had genuinely chosen to record everything — and the only way the old default let it say so was a comment noting the field was being left alone, indistinguishable in the code from never having considered it. Every other unset field was the absence of a decision, read as "record every success": the expensive answer, and the one that buries what anyone queries the dataset for.

A default nobody can see they are accepting is not a default anyone has agreed to. This release moves it to the value that is right when nobody has thought about it, and leaves the two reasons to move off it — 400 for client errors, 0 for rate and latency — documented on the field.

⚠️ Breaking Changes

  • A Worker that does not set analytics.minRequestStatus stops recording 2xx and 4xx request measurements after upgrading, with no code change on its side. The threshold check itself is unchanged — AnalyticsService.request still returns false without writing when status < minRequestStatus — only the default it reads.

    This is a patch by the surface rule in Publishing: no export is removed, renamed, or narrowed, and AnalyticsSettings is the same shape it was in 1.2.1. It is still a behaviour change, and the deployments it silently affects are exactly the ones that never named the field. If you query request rate, latency percentiles, or anything else needing successes in the denominator, set minRequestStatus: 0 before upgrading — the data you do not record is not recoverable afterwards.

  • AnalyticsService.event is unaffected, as it has been since 1.1.0. A domain metric does not describe a response, so no status threshold applies to it.

🚀 Features

  • None. No new export, no new setting, no new member on an existing interface. Everything this release does, it does by changing one value in cloudflareDefaults — which is why it lands as a patch.

🔧 Enhancements

  • cloudflareDefaults.analytics.minRequestStatus is 500. The default now expresses an opinion: a dataset holds the requests that failed. A Worker overriding it says so in its own configure() call, where the next person reading that Worker can see the choice was made.

  • wrangler.json carries its $schema and moves to a 2026-08-28 compatibility date, with the binding arrays ordered as the reference documentation lists them. Repository configuration only — nothing in package.json#files changes — but this file is what a consumer copies when wiring their own bindings, so its ordering is documentation.

🐛 Bug Fixes

  • One test passed for the wrong reason. drops the point when the dataset is unbound asserted false on a 200, which under a 500 default the threshold filters out before the unbound-binding path it exists to cover is ever reached. It now passes a 500. Nothing shipped was broken — the coverage was — and moving a default is exactly the kind of change that exposes it.

🔐 Security

  • None.

🧪 Tests

npm run lint, npm run test:run, and npm run build all clean. 109 specs across nine suites, up from 105.

  • The default-threshold block in test/core/services/AnalyticsService.spec.ts was rewritten rather than deleted: a 200 and a 404 are skipped, a 500 is recorded.
  • A new block covers minRequestStatus: 0, which had no coverage precisely because it used to be the default.
  • test/middlewares/logger.spec.ts gained the same split through the middleware: no metric for /ok, none for /missing, one for /broken.

📚 Documentation

  • AnalyticsSettings.minRequestStatus is written around the new default, naming 400 and 0 as the two reasons to move off it rather than presenting 0 as the baseline.
  • AnalyticsService.request and the analytics block of cloudflareDefaults say 500 where they said 0.

⬆️ Upgrading

npm install @bayudwiyansatria/cloudflare@1.2.2

If your Worker already sets analytics.minRequestStatus, nothing changes — an explicit value has always won over the default and still does.

If it does not, decide which of these you are before deploying:

// Failures only. The new default; nothing to write.
configure({ ...systemDefaults, ...cloudflareDefaults })

// Failures and client errors.
configure({ ...systemDefaults, ...cloudflareDefaults }, { analytics: { minRequestStatus: 400 } })

// Everything, because request rate and latency percentiles are queried from this dataset.
configure({ ...systemDefaults, ...cloudflareDefaults }, { analytics: { minRequestStatus: 0 } })

Per-field merge applies as everywhere else, so naming minRequestStatus keeps the default binding and enabled.

Write the value down even when it matches the default. A pinned 0 is what keeps a release like this one from silently reversing a decision you had already made.

🚨 Known Issues

  • None

📦 Dependencies

No change. @bayudwiyansatria/core stays at ^1.2.1.

👥 Contributors

  • Bayu Dwiyan Satria

🙏 Acknowledgments

Thanks to everyone who ran 1.1.0 in production and reported what the dataset looked like afterwards. The case for this change is entirely theirs.

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

results matching ""

    No results matching ""