Skip to content

zcode: count five-hour resets expiring soon - #368

Draft
cat-xierluo wants to merge 1 commit into
magpie-community:mainfrom
cat-xierluo:plugin-zcode-resets-expiring-soon
Draft

cat-xierluo wants to merge 1 commit into
magpie-community:mainfrom
cat-xierluo:plugin-zcode-resets-expiring-soon

Conversation

@cat-xierluo

Copy link
Copy Markdown

Why

The ZCode usage card already reports each available reset's until in resets.each. A caller still has to scan that list and compare timestamps to discover that a five-hour reset is about to lapse.

Change

Add resets.fiveHourExpiringSoon when one or more available five-hour resets expire within two hours. The count covers personal and team resets and does not alter weekly reset data or perform any reset action.

Tests

  • HOME=$(mktemp -d) bun test packages/zcode/usage.test.mjs — 17 passed
  • bun scripts/check.mjs zcode — passed
  • git diff --check — passed

Expose fiveHourExpiringSoon from the available reset cards so callers can spend a five-hour reset before it lapses.
@yetone

yetone commented Oct 25, 2026

Copy link
Copy Markdown
Contributor

Thanks for this, @cat-xierluo. I read it at cec7291 and ran bun test packages/zcode in a sandbox HOME (it passes). I can't merge it as it is:

  1. Nothing reads the new field. magpie's plugin host copies a usage card's resets field by field (internal/plugin/host.js, the resets: block of the usage normaliser: count, until, byWindow, fiveHour, weekly, team, each), and plugin.UsageResets in internal/plugin/providers.go has no other field. So fiveHourExpiringSoon is dropped before magpie, the GUI, the TUI or any caller sees it. resets.each already carries each reset's until and window, and it does reach magpie. "A reset runs out within two hours" is a thing for magpie's card to show from each, so it belongs in magpie, not in one plugin's output. If you want it, please open it on yetone/magpie (Discord #feedback works too) as a card feature, so every plugin that reports resets gets it.
  2. The team test can fail at a second boundary. It calls Date.now() once in the fake's expireTime and again in the expected until, and both are truncated to seconds. When the second ticks over between those two calls, the expectation is one second off and the test goes red. Compute the value once and use it in both places.
  3. An available reset that has already expired counts as "soon". Date.parse(x.until) - Date.now() < 2h is true for a time in the past too. It needs a lower bound of 0.
  4. No version bump. A change to index.mjs needs packages/zcode/package.json raised (main is at 0.1.27, and 0.1.28 is about to land for zcode: a team seat lists no -Trial models and its card doesn't say why #359), or it's never published.

I'm leaving this open in case you want to rework it, but point 1 means the plugin-side field won't be shown anywhere.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants