Update workflow status in place without a page reload - #11
Merged
Conversation
Schedule status only changed on a manual browser refresh, so watching a dispatched run meant reloading the page repeatedly. Poll getSchedules() every 10s while any schedule is non-terminal - pending, processing, or triggered with no conclusion yet. Once everything has settled no timer is started and no requests are issued. Polling faster would not help: the cron tick that writes these rows runs once a minute, so the badge is at most ~70s behind the GitHub run either way. Also adds a Refresh button and an "updating…" indicator beside the Pending and History headers, shown for the background poll as well as the manual click. Two details worth noting: - fetchSchedules holds the in-flight promise rather than a boolean, so overlapping calls collapse onto one request. A slow response can therefore never land after a newer one and repaint "running…" over an already-resolved "succeeded", and a click racing the poll timer still awaits a real result. - The indicator is held for a 400ms floor. A schedule read finishes well under 100ms, so without it the indicator would flash for a single frame every poll. Data still renders as soon as it arrives. The indicator is aria-hidden: it repeats every 10s, and a live region announcing it that often would bury the badge change that actually matters. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
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
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.
Problem
Schedule status only updated on a manual browser reload. Watching a dispatched run meant hitting refresh over and over.
Approach
Poll
getSchedules()every 10s while any schedule is non-terminal —pending,processing, ortriggeredwith no conclusion yet. When everything has settled, no timer starts and no requests are issued.10s is deliberate, not arbitrary: the cron tick that writes these rows runs once a minute, so the badge is at most ~70s behind the real GitHub run regardless. Polling faster buys nothing.
Adds a Refresh button, and an
updating…indicator beside the Pending and History headers that shows for the background poll as well as the manual click.Details worth a look in review
fetchSchedulesholds the in-flight promise, not a boolean. Overlapping calls collapse onto one request, so a slow response can't land after a newer one and repaintrunning…over an already-resolvedsucceeded. A click racing the poll timer still awaits a real result rather than no-op'ing.aria-hidden. It repeats every 10s; a live region announcing it that often would bury the badge change that actually matters. Happy to reverse this if you'd rather it announce.disabledwhile fetching. The promise dedupe already collapses concurrent clicks, and disabling it would grey the button out every 10s on its own.Trade-off
A tab left open with a schedule days out polls every 10s the whole time. An earlier version slept until the schedule came due, but that cost ~77 lines (a helper module, a
nowstate, a two-branch timer) to optimise a case that only bites if you leave a tab open for days. Cut it deliberately.Testing
npx tsc --noEmitclean,npx eslint .clean,npx vitest run84 passing.No automated coverage for the polling itself — it's
useEffecttimer behavior with no test harness for components in this repo (vitestruns innode, no DOM). Verified by hand in the running dev app.🤖 Generated with Claude Code