fix(dashboard): show queued state before empty state during refresh - #69749
Conversation
tiles briefly lost their queued status in the render gap between the refreshDashboardItems reset and the re-mark, so they showed the query's default empty state instead of loading while queued Generated-By: PostHog Code Task-Id: 966d80aa-fd45-4279-9af7-e20222c29044
🦔 Hogbox preview · ✅ ready▶ Open the preview
commit |
|
Reviews (1): Last reviewed commit: "fix(dashboard): show queued state before..." | Re-trigger Greptile |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
Small, low-risk UI state-ordering fix within the author's own team; no risky territory touched and no unresolved concerns.
- Author wrote 0% of the modified lines and has 101 merged PRs in these paths (familiarity MODERATE).
- 👍 on the PR from greptile-apps[bot], hex-security-app[bot].
Gate mechanics and policy version
| Gate | Result | |
|---|---|---|
| prerequisites | ✓ | all clear |
| deny-list | ✓ | no deny categories matched |
| size | ✓ | 12L, 1F substantive — within ceiling |
| tier | ✓ | T1-agent / T1a-trivial (12L, 1F, single-area, fix) |
| stamphog 2.0.0b3 | .stamphog/policy.yml @ 280e388 · reviewed head 32afe2b |
🤖 CI report✅ Bundle size — no changeUncompressed size of every built Total: 69.86 MiB · no change No file changed by more than 1000 B. Posted automatically by build-bundle-size-report · uncompressed bytes from dist-report ✅ Eager graph — within budgetHow much code each root ships on the eager path — downloaded and parsed before the surface is interactive. Measured from the esbuild output chunks (post-tree-shake, static imports only); lazy
🟢 Largest files eagerly shipped from
|
| Size | File |
|---|---|
| 126.8 KiB | ../node_modules/.pnpm/react-dom@18.3.1_react@18.3.1/node_modules/react-dom/cjs/react-dom.production.min.js |
| 24.6 KiB | ../node_modules/.pnpm/buffer@6.0.3/node_modules/buffer/index.js |
| 6.3 KiB | ../node_modules/.pnpm/react@18.3.1/node_modules/react/cjs/react.production.min.js |
| 4.5 KiB | ../node_modules/.pnpm/@jspm+core@2.1.0/node_modules/@jspm/core/nodelibs/browser/process.js |
| 3.9 KiB | ../node_modules/.pnpm/scheduler@0.23.2/node_modules/scheduler/cjs/scheduler.production.min.js |
| 1.4 KiB | ../node_modules/.pnpm/base64-js@1.5.1/node_modules/base64-js/index.js |
| 1.3 KiB | src/RootErrorBoundary.tsx |
| 912 B | ../node_modules/.pnpm/ieee754@1.2.1/node_modules/ieee754/index.js |
| 789 B | src/scenes/ChunkLoadErrorBoundary.tsx |
| 668 B | src/index.tsx |
Largest files eagerly shipped from src/scenes/AuthenticatedShell.tsx
| Size | File |
|---|---|
| 277.1 KiB | ../node_modules/.pnpm/posthog-js@1.398.2/node_modules/posthog-js/dist/rrweb.js |
| 266.9 KiB | ../node_modules/.pnpm/@posthog+icons@0.37.4_react-dom@18.3.1_react@18.3.1__react@18.3.1/node_modules/@posthog/icons/dist/posthog-icons.es.js |
| 224.6 KiB | src/taxonomy/core-filter-definitions-by-group.json |
| 213.6 KiB | ../node_modules/.pnpm/posthog-js@1.398.2/node_modules/posthog-js/dist/module.js |
| 164.0 KiB | src/queries/validators.js |
| 154.0 KiB | ../node_modules/.pnpm/re2js@0.4.1/node_modules/re2js/build/index.esm.js |
| 126.8 KiB | ../node_modules/.pnpm/react-dom@18.3.1_react@18.3.1/node_modules/react-dom/cjs/react-dom.production.min.js |
| 105.7 KiB | src/lib/api.ts |
| 93.3 KiB | ../node_modules/.pnpm/prosemirror-view@1.40.1/node_modules/prosemirror-view/dist/index.js |
| 90.5 KiB | ../node_modules/.pnpm/@tiptap+core@3.20.1_@tiptap+pm@3.20.1/node_modules/@tiptap/core/dist/index.js |
Posted automatically by check-eager-graph · sizes are eager output bytes (shipped, post-tree-shake) from the esbuild metafile · part of #32479
⚠️ Dist folder size — 🔺 +687 B (+0.0%)
Total size of the built frontend/dist folder (all assets), compared against the base branch.
Total: 1433.63 MiB · 🔺 +687 B (+0.0%)
|
👋 Visual changes detected for this PR. Review and approve in PostHog Visual Review If these changes are unexpected, they may be caused by a flaky test or a broken snapshot on master. Don't approve — rerun the job or wait for a fix. |
1 participant
Problem
Dashboard SQL insights briefly show "No matching events" while queued for refresh, before flipping to the loading state once the refresh actually starts. Easy to misread as "no data" rather than "not refreshed yet".
Reported in support ticket #2707.
Changes
refreshDashboardItemsresetsrefreshStatusto{}the moment it dispatches, then didawait breakpoint()before re-marking stale tiles asqueued: true. That await opened a real render window where tiles had no refresh status at all, soInsightCardfell through to the query's default empty state instead of showing the queued/loading state.Moved the
setRefreshTilesTotal/setRefreshStatusescalls to before theawait breakpoint(), closing the gap.How did you test this code?
Read through
dashboardLogic.tsx's refresh listener andInsightCard.tsx's empty/loading state branching to confirm the render gap and that the reorder closes it. Did not manually reproduce in a running instance.Docs update
N/A - no user-facing API or config change.
🤖 Agent context
Autonomy: Fully autonomous
Investigated and fixed via PostHog Code, based on support ticket #2707. Traced the bug from
InsightCard.tsx's loading/empty branching back todashboardLogic.tsx'srefreshStatusreducer and therefreshDashboardItemslistener, then closed the race between the reducer's reset and the listener'sawait breakpoint().Created with PostHog Code