-
Notifications
You must be signed in to change notification settings - Fork 151
Fix automatic workflow run updates with improved polling mechanism #541
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
…s; refine run polling log output
|
Related #285 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
This PR implements an automatic polling mechanism to update workflow runs in real-time without requiring manual refresh, addressing issue #229. The solution adds intelligent polling that respects window focus and view visibility to minimize unnecessary API calls.
Key changes include:
- Automatic polling for active workflow runs (in_progress, queued, waiting, requested) with a 4-second interval for up to 15 minutes
- Window focus and view visibility tracking to pause polling when the extension is not in use
- Enhanced workflow trigger command that waits for new runs to appear and automatically starts polling them
Reviewed changes
Copilot reviewed 7 out of 7 changed files in this pull request and generated 10 comments.
Show a summary per file
| File | Description |
|---|---|
| src/treeViews/workflows.ts | Exports WorkflowsTreeNode type to enable access from other modules |
| src/treeViews/workflowRunTreeDataProvider.ts | Adds automatic polling initiation for active workflow runs when tree nodes are created |
| src/treeViews/treeViews.ts | Tracks workflow tree view visibility state and notifies the store |
| src/store/workflowRun.ts | Unconditionally clears job cache on run updates to ensure polling fetches latest job status |
| src/store/store.ts | Implements polling mechanism with focus/visibility checks and cleanup logic for completed runs |
| src/extension.ts | Registers window state change handler to track focus state |
| src/commands/triggerWorkflowRun.ts | Enhanced to detect newly triggered runs and automatically start polling them |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| if (!this._isFocused || !this._isViewVisible) { | ||
| return; | ||
| } | ||
|
|
||
| log(`Fetching run update: ${updater.runId}. Remaining attempts: ${updater.remainingAttempts}`); | ||
|
|
||
| updater.remainingAttempts--; |
Copilot
AI
Dec 19, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The fetchRun method skips the API call when the window is not focused or view is not visible, but it still decrements remainingAttempts (line 87). This means if the window is unfocused for a long time, the remaining attempts could be exhausted without making any API calls. When the user returns to the window, polling may have already stopped. Consider only decrementing remainingAttempts when an API call is actually made.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@copilot open a new pull request to apply changes based on this feedback
| // Auto-poll active runs | ||
| if ( | ||
| workflowRun.run.status === "in_progress" || | ||
| workflowRun.run.status === "queued" || | ||
| workflowRun.run.status === "waiting" || | ||
| workflowRun.run.status === "requested" | ||
| ) { | ||
| // Poll every 4 seconds for up to 15 minutes (225 attempts) | ||
| this.store.pollRun(workflowRun.run.id, gitHubRepoContext, 4000, 225); |
Copilot
AI
Dec 19, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The pollRun method in workflowRunTreeDataProvider is called every time runNodes is invoked, which could be during tree refreshes. This means that active runs that are already being polled will have their polling restarted with full attempts (225), potentially creating multiple polling intervals for the same run. The store's pollRun does clear the existing interval before creating a new one, but this restart behavior may not be desired. Consider checking if polling is already active for a run before starting new polling.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@copilot open a new pull request to apply changes based on this feedback
| // Poll every 4 seconds for up to 15 minutes (225 attempts) | ||
| this.store.pollRun(workflowRun.run.id, gitHubRepoContext, 4000, 225); |
Copilot
AI
Dec 19, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Magic numbers 4000 and 225 are used directly without explanation. While there is a comment stating "Poll every 4 seconds for up to 15 minutes", having these values as named constants would improve maintainability and make it easier to adjust the polling strategy across the codebase. Consider defining constants like POLL_INTERVAL_MS and MAX_POLL_ATTEMPTS.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@copilot open a new pull request to apply changes based on this feedback
| const relativeWorkflowPath = vscode.workspace.asRelativePath(workflowUri, false); | ||
| if (!workflowIdForApi) { | ||
| workflowIdForApi = basename(workflowUri.fsPath); |
Copilot
AI
Dec 19, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The workflowIdForApi is set twice when args is a vscode.Uri - once at line 27 and again at line 56. The second assignment is redundant since the condition "!workflowIdForApi" will never be true when args is a Uri. Consider restructuring this logic to avoid the unnecessary check and assignment.
| ); | ||
| } | ||
|
|
||
| return vscode.commands.executeCommand("github-actions.explorer.refresh"); |
Copilot
AI
Dec 19, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After the loop completes (either by finding the new run or exhausting 20 attempts), the code always calls the refresh command at line 207. However, if a new run was found and already triggered a refresh at line 194, this results in a redundant refresh. Consider skipping the final refresh if the new run was already detected and refreshed.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Description
This PR fixes issue #229 where newly triggered workflow runs required manual refresh to see updates in the UI. The extension now automatically polls for workflow run updates and reflects changes in real-time.
Changes
Enhanced Polling Mechanism
Key Improvements
Related Issues
Fixes #229
Testing
The fix ensures that: