feat(dashboard): auto-refresh CronPage every 30s - #57307
Open
ayounce80 wants to merge 1 commit into
Open
Conversation
CronPage loaded its job list on mount and after the user's own mutations only — a cron job firing, failing, or being edited by the CLI/another process stayed invisible until a manual page reload. SessionsPage already polls for exactly this reason (separate processes share one session DB; no push channel yet). Add a silent 30s background refresh alongside the existing mount load, mirroring the SessionsPage pattern: errors in a background tick are swallowed rather than toasted, and the interval re-arms when the selected profile changes. Stopgap until a server-push state channel exists.
alt-glitch
added
type/feature
teknium1
reviewed
Jul 15, 2026
teknium1
left a comment
teknium1
left a comment
Contributor
There was a problem hiding this comment.
Thanks for addressing the stale cron-state gap. The premise holds on current main: CronPage loads jobs on mount at web/src/pages/CronPage.tsx:606-608, while SessionsPage already uses an interval at web/src/pages/SessionsPage.tsx:904-931 for cross-process state.
Problems
- The added
.then(setJobs)atweb/src/pages/CronPage.tsx:619accepts an in-flight response after its interval has been cleaned up. If the selected profile changes, an older request can overwrite the new profile's list; overlapping interval requests can also resolve out of order. The existing cancellation pattern atweb/src/pages/CronPage.tsx:613-627shows the needed guard shape.
Suggested changes
- Gate polling results with a cancellation flag or request generation so only the current profile/latest request may call
setJobs; consider applying that ordering protection toloadJobsas well. - Add a deferred-promise/fake-timer regression test for profile switching or out-of-order responses.
Automated hermes-sweeper review.
| const id = setInterval(() => { | ||
| api | ||
| .getCronJobs(selectedProfile) | ||
| .then(setJobs) |
Contributor
There was a problem hiding this comment.
Clearing this effect's interval does not cancel a request that has already reached getCronJobs. If the user switches profiles, or a later tick finishes first, this response can overwrite the current list. Gate the result with a cleanup flag or request generation before calling setJobs.
teknium1
added
sweeper:risk-compatibility
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Split out of #57265 (closed as duplicate of #54887 on the auth side) per triage.
CronPage renders once and never refreshes — job state (last run, next run, enabled, last_status) goes stale until a manual reload, unlike SessionsPage which already background-refreshes. This applies the same silent 30s background-refresh pattern SessionsPage uses (~15 lines, no visual flicker: refresh skips the loading state when data is already present).
Verified with
npx tsc --noEmitand live on a private deployment (job state updates land within 30s of a cron fire, no observed re-render flicker).Related: #55130 discusses the underlying polling-vs-push question for the dashboard broadly; this is the minimal parity fix for CronPage in the meantime.