feat(seer): Poll live autofix run status on overview - #122191
feat(seer): Poll live autofix run status on overview#122191NicoHinderling wants to merge 1 commit into
Conversation
github-actions
Bot
added
the
Scope: Frontend
📊 Type Coverage Diff
🔍 1 new type safety issue introducedType assertions (
This is informational only and does not block the PR. |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
87ecd86 to
7c2d84f
Compare
f19eb51 to
459b433
Compare
459b433 to
9075548
Compare
| const source = enrichedQuery.data ?? statusPollQuery.data; | ||
| const data = useMemo( | ||
| () => (source ? overlayStatus(source, statusPollQuery.data) : undefined), | ||
| [source, statusPollQuery.data] |
There was a problem hiding this comment.
Stale poll status overwrites newer data
Medium Severity
overlayStatus always prefers the status-poll payload over enrichment, but both queries request status and can finish out of order. A slower or earlier poll can overwrite a newer enriched status, so the Working spinner can linger or reappear until the next poll even after a run has already completed.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit 9075548. Configure here.
There was a problem hiding this comment.
Deferring this one — it's a brief, self-healing case: if an enriched refetch lands with a newer status than the last 10s poll, the poll can revert it until the next poll corrects it (≤10s). Fixing it properly needs a per-run freshness marker (a timestamp/version) that neither this endpoint nor Seer exposes today, so it belongs with the planned v2 work (push/SSE + versioning) rather than this PR.
| if (status === 'processing') { | ||
| return ( | ||
| <Flex align="center" gap="xs"> | ||
| <LoadingIndicator mini /> | ||
| <Text size="sm" variant="muted"> | ||
| {t('Working…')} | ||
| </Text> | ||
| </Flex> | ||
| ); | ||
| } |
There was a problem hiding this comment.
Bug: The component may incorrectly show a loading spinner for a merged run if its status is 'processing', because the status check happens before the section-specific logic for 'merged' runs.
Severity: LOW
Suggested Fix
Reorder the conditional logic. Check if sectionKey === 'merged' first, and render the merged UI. Then, in a subsequent else if, check for status === 'processing' to show the spinner for other sections. This ensures the 'merged' state always takes precedence over the 'processing' state.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.
Location: static/app/views/seerWorkflows/overview/issueCard.tsx#L149-L158
Potential issue: The component's logic prioritizes showing a loading spinner for any run
with `status === 'processing'`. This check occurs before the logic that handles runs in
the 'merged' section. If a backend state inconsistency were to cause a run to be in the
'merged' section while still having a 'processing' status, the UI would incorrectly
display a loading spinner instead of the expected UI for a merged pull request. While
the backend is designed to prevent this state, the frontend does not defensively handle
this possibility.
There was a problem hiding this comment.
Deferring this one: a run only appears in the Merged section after its PR is merged, and by then Seer's run has finished — so a merged run is never processing, and the spinner can't show here. Since the merged-and-still-processing case can't actually happen, the check order doesn't produce a wrong spinner in practice.
9075548 to
b9c1f1c
Compare
Poll the overview endpoint with expand=status every 10s (paused when the tab is hidden) alongside the enriched request, and overlay the freshest per-run status onto the cards so a run actively working shows a "Working…" spinner. A section signature computed from each poll refetches enrichment only when a run changes section, and a best-effort poll that returns null never clobbers a status already known.
b9c1f1c to
de70d94
Compare
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
There are 2 total unresolved issues (including 1 from previous review).
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit de70d94. Configure here.
1 participant
Polls live Autofix run status on the overview page so cards show a "Working…" spinner while a run is actively processing, and so a card moves sections (e.g. a PR merged directly on GitHub → "Merged") within ~10s — even when no run is running.
How
expand=statuspoll everyPOLL_INTERVAL(10s), alongside the enriched (scmInfo/issueStats/status) request. The poll pauses when the tab is hidden.seerRunId), so spinners update without re-fetching enrichment.(seerRunId, milestone)section signature is computed from each poll; when it changes (a run moved section, or appeared/disappeared) the enriched request is silently refetched, so badges/counts and bucketing stay consistent.OverviewActionrenders aWorking…spinner when a run's status isprocessing.Notes
statusexpand) and blocked on that backend deploying — the poll is a no-op (status: null) until the endpoint ships.