Conversation
What changed: - added a browser-side usage cache helper that stores the last successful usage snapshot per account in localStorage - rehydrated account cards from the cached usage data before live refreshes complete and kept the cached timestamp on each account - updated the usage UI to keep stale data visible while a refresh is in flight instead of blanking the card Why: - a full reload currently drops all usage information until every account finishes refetching - keeping the last known good snapshot makes the dashboard useful immediately after restart and during slow refreshes Impact: - usage bars can render cached values right after the app starts, including after a restart - refreshes now feel stale-while-revalidate instead of clearing the previous state first Validation: - ran pnpm build
What changed: - persisted the last successful usage snapshot in the accounts store and exposed it in account payloads - merged backend snapshots with the browser cache so startup can render the previous usage values immediately - dimmed loading usage bars and added a light sheen animation to show the visible values are stale while refresh is running Why: - the existing PR still fell back to placeholder loading state on relaunch because the cached values were not reliably available at startup - once stale values were visible, the UI still needed a clearer visual distinction between stale data and freshly loaded data Impact: - reopening the app now keeps the previous limit bars visible during refresh instead of showing an empty skeleton - users can tell at a glance that the numbers are being refreshed and are not yet the newest values Validation: - pnpm exec tsc --noEmit - cargo check --manifest-path src-tauri/Cargo.toml
What changed: - stopped the account card from inventing a fresh "Last updated" time when cached usage exists without a real persisted timestamp - exported the usage reset formatter with an injectable reference time so the scale timing logic can be verified in isolation Why: - this PR should only absorb the display-side usage-cache follow-up from main without pulling in the unrelated web runtime, live auth, or theme work - showing "Just now" without a stored timestamp makes the preserved usage state look fresher than it really is Impact: - the usage card now reflects only real persisted refresh times - the reset-window formatter is easier to validate while the PR scope stays focused on cached usage display behavior Validation: - ran pnpm build - verified the long-window and sub-day formatResetTime outputs via a temporary transpiled runtime check
Lampese
left a comment
Lampese
left a comment
There was a problem hiding this comment.
Requesting changes for two behavioral/storage issues:
-
The stale-while-refresh behavior does not actually hold in soft-failure cases. The backend usage layer often returns
UsageInfo::error(...)as a successful result instead of throwing, and the frontend then goes throughapplyUsageFetchResult, which replaces the previously cached usage with that error object. In practice, that means a refresh that comes back with an API error can still wipe the old snapshot from the card instead of preserving it while stale. -
This feature is presented as persisting usage snapshots in browser localStorage, but it also writes every successful snapshot back into
accounts.jsonon the Rust side. With the existing 60-second auto-refresh loop, that turns a lightweight UI cache into repeated full rewrites of the main credential store that also contains refresh tokens and API keys. That coupling feels too heavy for what should be cache data, especially since this branch is still using plainfs::writefor the store file.
I think both issues should be resolved before merging. The stale-data promise should survive soft API failures, and the cache persistence should not introduce high-frequency writes to the primary account database unless that tradeoff is very intentionally designed.
2 participants
Summary
Why
A full reload currently drops all usage information until every account finishes refetching. This keeps the dashboard informative immediately after restart and during slow usage refreshes.
Testing