You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@maka.apache.org by "GabrielDrapor (via GitHub)" <gi...@apache.org> on 2026/08/22 08:34:46 UTC
[PR] fix(desktop): reload usage stats when the persisted range arrives [maka]
GabrielDrapor opened a new pull request, #3476:
URL: https://github.com/apache/maka/pull/3476
## Symptom
Settings remembers the last-open page. When a Settings window is restored **directly onto 使用统计**, every metric reads **0** under a correct-looking range chip (typically 全部) — until a manual refresh, or navigating away and back:
## Root cause
The section-change effect fetched usage stats exactly once:
```ts
useEffect(() => {
if (section === 'usage') void reloadUsage();
}, [section]);
```
`reloadUsage()` defaults its range to `settings.usage.range` — but when the window restores straight onto this page, the Runtime Host settings are still loading, so `settings` is `createDefaultSettings()` and the fetch runs with the **`'24h'` default**. The persisted range then lands and moves the selected chip (e.g. to 全部), but nothing refetches: the page shows the default range's (often empty) dataset under the persisted range's chip. A manual refresh uses the live draft range and a tab round-trip re-fires the effect after settings are ready — which is why both "fix" it.
## Fix
- The section effect is keyed on the **effective range** and passes it explicitly — the persisted range's arrival (or any later range change) triggers the reload, and the effect is the single owner of range-driven fetches.
- The page's range chips now only persist; the surface refetches when the persisted value lands, instead of racing a second fetch against it.
## Regression
New story `UsagePersistedRangeRestore`: the bridge resolves `settings.get()` a beat late and serves stats **only** for the persisted `'all'` range; the story renders `SettingsStory section="usage"` (the restore path) and the play function asserts the totals come from the persisted range's dataset. Under the previous code the play times out — the mount-time `'24h'` fetch was the only one.
Verified: renderer + storybook tsconfigs compile; Desktop suite 1092 green; biome clean.
Co-Authored-By: Claude <no...@anthropic.com>
https://claude.ai/code/session_01TMwYxgNEbz2RFmuK6AXGcj
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [PR] fix(desktop): reload usage stats when the persisted range arrives [maka]
Posted by "Astro-Han (via GitHub)" <gi...@apache.org>.
Astro-Han commented on code in PR #3476:
URL: https://github.com/apache/maka/pull/3476#discussion_r3835658036
##########
apps/desktop/stories/settings/settings-pages.stories.tsx:
##########
@@ -1293,6 +1294,49 @@ export const UsageNarrow: Story = {
...UsageLongTail,
parameters: { viewport: { defaultViewport: 'mobile2' } },
};
+
+/** The persisted range lands with the (async) settings load, after the
+ * section effect's first fetch already ran with the '24h' default. A
+ * Settings window restored directly onto 使用统计 must refetch when the
+ * persisted range arrives — without that, the page shows the default
+ * range's (empty) numbers under the persisted range's selected chip until
+ * a manual refresh. The bridge makes the race explicit: stats exist only
+ * for the persisted 'all' range, and settings resolve a beat late. */
+const withUsagePersistedRangeBridge = (() => {
+ const settings = mergeSettings(createDefaultSettings(), { usage: { range: 'all' } });
+ return withScopedMakaBridge({
+ ...makaBridge,
+ settings: {
+ ...makaBridge.settings,
+ get: async () => {
Review Comment:
[P2] `usage` is client-owned, so the page projects its persisted range from `settings.getClient()`, not this Runtime Host `get()`. The unchanged client bridge still returns the default `24h`; this story therefore never reaches the intended persisted `all` state, and its play assertion would time out (the regular Storybook smoke does not execute play functions). Could the bridge delay/return `getClient()` with `usage.range = 'all'` instead, or seed that client setting directly? That would make the regression test exercise the real authority.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [PR] fix(desktop): reload usage stats when the persisted range arrives [maka]
Posted by "GabrielDrapor (via GitHub)" <gi...@apache.org>.
GabrielDrapor commented on PR #3476:
URL: https://github.com/apache/maka/pull/3476#issuecomment-5379519949
Fixed at head `f9c7aa644` — you're right on both counts: `usage` is client-owned (`settings-ownership.ts` projects `usage: client.usage`), so the persisted range rides in through `getClient()`, and my bridge was delaying the wrong channel.
The story bridge now seeds and delays `getClient()` (with `updateClient` routed to the same object) and leaves the Runtime Host `get()` stock — so the play exercises the real authority transition: mount fetch with the '24h' default → late-resolving client settings land `range: 'all'` → the keyed effect refetches → totals from the 'all' dataset render. The production-code comment that misattributed the source to the Runtime Host settings load is corrected to name the client channel as well.
(While in there I noticed the neighboring `withUsageStoryBridge` helper routes its `usage` overrides through the Runtime Host `get()`/`update` too, so the existing Usage stories' `activeTab`/`showDetails` seeds don't actually reach the page either — left untouched here as it predates this PR, but happy to fix it in a follow-up if you'd like.)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [PR] fix(desktop): reload usage stats when the persisted range arrives [maka]
Posted by "Astro-Han (via GitHub)" <gi...@apache.org>.
Astro-Han merged PR #3476:
URL: https://github.com/apache/maka/pull/3476
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org