Skip to content

Conversation

@aldevv
Copy link
Contributor

@aldevv aldevv commented Dec 15, 2025

Summary by CodeRabbit

  • Bug Fixes
    • Improved action invocation reliability by adding background status polling until completion, respecting cancellation, and using the final polled status and response to determine success or failure—reducing false failures and ensuring returned results reflect the completed action.

✏️ Tip: You can customize this high-level summary in your review settings.

@coderabbitai
Copy link

coderabbitai bot commented Dec 15, 2025

Walkthrough

Adds a polling loop after action invocation that repeatedly calls GetActionStatus every 1s while status is BATON_ACTION_STATUS_PENDING, updates the local status/response from each poll, respects context cancellation, and uses the final polled status to determine error return.

Changes

Cohort / File(s) Change Summary
Action Status Polling
pkg/tasks/local/action_invoker.go
Replaced immediate failure check after InvokeAction with a polling loop that calls GetActionStatus every 1s while status is BATON_ACTION_STATUS_PENDING; respects context cancellation, updates status and final response from each poll, logs final response, and returns an error if final status is BATON_ACTION_STATUS_FAILED.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

  • Verify loop termination for non-pending statuses and on context cancellation.
  • Check handling and propagation/logging when GetActionStatus returns an error during polling.
  • Confirm final error construction and logging use the latest resp.GetResponse() and status.

Poem

🐰 I waited by the tiny light,

One-second hops through day and night,
I asked the baton, soft and keen,
Till status changed and all was seen,
A carrot dance for code that's right! 🥕

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title 'add polling for action status' directly describes the main change: replacing immediate failure checks with a polling loop for action status, as evidenced by the implementation changes in action_invoker.go.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch add_polling_action

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 6304eae and d4fe7c7.

📒 Files selected for processing (1)
  • pkg/tasks/local/action_invoker.go (1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
  • GitHub Check: go-test (1.25.2, windows-latest)

Comment on lines 78 to 82
l.Info("ActionInvoke response", zap.Any("resp", resp))

if resp.GetStatus() == v2.BatonActionStatus_BATON_ACTION_STATUS_FAILED {
if status == v2.BatonActionStatus_BATON_ACTION_STATUS_FAILED {
return fmt.Errorf("action invoke failed: %v", resp.GetResponse())
}
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Error message uses stale response data.

After polling, status reflects the latest state, but line 81 uses resp.GetResponse() from the initial InvokeAction call. If the action failed during execution, the failure details would be in the final polled response, not the original one.

Consider capturing the final response from polling:

+	var finalResp *v2.InvokeActionResponse = resp
 	for status == v2.BatonActionStatus_BATON_ACTION_STATUS_PENDING {
 		// ... polling logic ...
+		// Update finalResp if GetActionStatus returns response data
 	}

-	l.Info("ActionInvoke response", zap.Any("resp", resp))
+	l.Info("ActionInvoke response", zap.Any("resp", finalResp))

 	if status == v2.BatonActionStatus_BATON_ACTION_STATUS_FAILED {
-		return fmt.Errorf("action invoke failed: %v", resp.GetResponse())
+		return fmt.Errorf("action invoke failed: %v", finalResp.GetResponse())
 	}

Note: Verify that GetActionStatusResponse provides the response data needed for the error message; if it uses a different type, adjust accordingly.

Committable suggestion skipped: line range outside the PR's diff.

🤖 Prompt for AI Agents
In pkg/tasks/local/action_invoker.go around lines 78 to 82, the error log on
failure uses resp.GetResponse() from the initial InvokeAction call which may be
stale; update the code to use the final polled response returned by the last
GetActionStatusResponse (or whatever variable holds the final status response)
when constructing the error message so failure details reflect the terminal
state — if the polled response type differs, extract the response payload or
error field from that type and include it in the fmt.Errorf call instead of
resp.GetResponse().

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (2)
pkg/tasks/local/action_invoker.go (2)

67-67: Consider whether 1-second polling interval is appropriate.

The ticker uses a 1-second interval, which is 10× slower than the 100ms suggested in previous review comments. This could delay completion detection by up to 1 second per poll. If actions typically complete quickly, a shorter interval (e.g., 250-500ms) might provide better responsiveness.


70-84: Good improvements, but consider adding a timeout or max retry limit.

The polling loop now correctly handles context cancellation and GetActionStatus errors, addressing the major concerns from previous reviews. However, if an action remains in PENDING/RUNNING indefinitely and the caller didn't provide a timeout context, this loop will spin forever.

Consider adding a safeguard:

+	const maxPollAttempts = 300 // 5 minutes at 1-second intervals
+	attempts := 0
+
 	ticker := time.NewTicker(1 * time.Second)
 	defer ticker.Stop()

 	for status == v2.BatonActionStatus_BATON_ACTION_STATUS_PENDING || status == v2.BatonActionStatus_BATON_ACTION_STATUS_RUNNING {
+		if attempts >= maxPollAttempts {
+			return fmt.Errorf("action polling timeout: exceeded %d attempts", maxPollAttempts)
+		}
+		attempts++
+
 		select {
 		case <-ctx.Done():
 			return ctx.Err()
📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 46ccd57 and 3f98e9a.

📒 Files selected for processing (1)
  • pkg/tasks/local/action_invoker.go (1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
  • GitHub Check: go-test (1.25.2, ubuntu-latest)
  • GitHub Check: go-test (1.25.2, windows-latest)
🔇 Additional comments (2)
pkg/tasks/local/action_invoker.go (2)

64-65: LGTM!

Good initialization of both status and response for subsequent polling updates.


86-89: LGTM!

Correctly uses finalResp from the polling loop for both logging and error reporting, ensuring failure details reflect the terminal state. This addresses the previous concern about stale response data.

@aldevv aldevv merged commit 3d45448 into main Dec 15, 2025
6 checks passed
@aldevv aldevv deleted the add_polling_action branch December 15, 2025 21:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants