Skip to content

Usage Pace 0.4.3 — honest stale readings

Choose a tag to compare

@scowalt scowalt released this 25 Oct 21:00
abe551c

Patch release for usage sources that keep returning their last successful reading when they cannot refresh an account.

Fixes

  • Old readings no longer look current. Normal polling still accepts cached observations. Once a reading reaches the configured usage-cache period (five minutes by default), Usage Pace checks that resource with refresh: true, at most once per cache period. If the forced response is still at least one cache period old at request start, or has no observation, the account is stale—even before a reset passes. Recent observations within the period are accepted without requiring an exact request-time timestamp. Manual refresh bypasses the probe limit.
  • Stale quota explains what happened. The strip tooltip, dialog, and CLI show the last successful reading's age, name the source that couldn't refresh the account, and include its reason when supplied. They no longer recommend another refresh immediately after that failure. Stale or unobserved quota remains “usage unknown,” without numeric pace, a zero-usage implication, or a stale forecast. Historical percentages remain in JSON with stale: true and null pace.
  • Known accounts keep their history through authentication failures. expired and unauthenticated results retain the account's prior windows, last-success timestamp, and omitted identity metadata, marked stale with a source-named state/reason. Retained accounts remain visible and count as unknown in their pool. A failed freshness probe also retains the cached reading it just received. Unknown identities stay separate; explicit identity changes never inherit another account's history.
  • Healthy duplicates still win. The 0.4.2 merging rule is unchanged: a stale or failed source cannot replace a healthy measurement of the same issued account identity. Other hosts, sources, and failure messages remain visible.

The full freshness rule is documented in README. This does not renew credentials or fix the upstream usage source. Release artifacts remain built with BB 0.44.0 / SDK 0.5.29; minimum requirements and dependency pins are unchanged. Saved resets remain read-only; the CLI JSON accounts/providers alias, token totals, and Codex-only --resets behavior are unchanged.

Verification

  • The four forced/unforced before- and after-reset regression cases failed against pristine 0.4.2 and passed with this fix. The full collector/account/integration regression set passed all 38 tests, including healthy on-demand refresh, weekly-only stale readings, probe throttling, retained source reasons/history, and healthy duplicates winning.
  • All 406 Vitest tests, 3 token-total tests, TypeScript, and release validation passed. TypeScript, the complete test suite, and release validation were rerun before merging.
  • Comment policy passed across 98 files with zero violations; all 13 policy regression tests passed. Staged policy, the ordinary pre-commit hook, and redacted secret scanning passed during preparation.
  • Production-only rebuilds and release validation passed with BB 0.44.0 / SDK 0.5.29 and BB's bundled npm 11.16.0, including version/SDK metadata, host digest, and isolated backend/host smoke loading. No provider requests were made by release validation.
  • Synthetic desktop/mobile browser checks showed B's last-read age, named source failure, and unknown quota without numeric pace or retry advice, alongside healthy A/Codex, the partial Claude pool, correct locations, and matching read-only resets. Strip widths 172/212/252px and desktop/mobile dialogs 1200/375px passed without horizontal overflow.
  • PR, resulting-main, and release-tag Woodpecker CI passed. The annotated v0.4.3 tag points to merge commit abe551ced35a827d2d92041b2b798ec20790dc96, whose tree exactly matches the reviewed and tested PR head.
  • Not yet verified: live installation or upgrade of 0.4.3 on either bb server. Only synthetic identities and example.test addresses are used in the regression evidence, recorded in multi-account verification.

New installations

bb plugin install 'git:https://github.com/scowalt/bb-plugin-usage-pace.git@v0.4.3'
bb plugin config usage-pace set showStrip true

The second command enables the optional strip. Use @^0.4.3 instead of the exact tag to track compatible releases.

Upgrades

Inspect the requested and resolved source first:

bb plugin source usage-pace

For repository/branch-tracking installs whose branch contains 0.4.3, or a release-range install that admits this tag, update in place and keep settings:

bb plugin update usage-pace

An exact tag or commit does not advance to a newer tag with update. Moving a pinned install, or changing an existing install to a tag or range, requires removal first. Removal deletes settings, secrets, and schedules. Record the current configuration and restore your settings after reinstalling:

bb plugin config usage-pace
bb plugin remove usage-pace
bb plugin install 'git:https://github.com/scowalt/bb-plugin-usage-pace.git@v0.4.3'

Use @^0.4.3 in the final command for compatible-release tracking. Do not use plugin install as an in-place upgrade: bb 0.46.1 rejects the duplicate plugin ID.

Publishing this release does not install, update, reload, or reconfigure plugins on either live bb server.

PR #9 · Full changelog