util/async: avoid blocking Append on Exec cancellation (#2034)

[ti-chi-bot]

This is an automated cherry-pick of #2034

Fix #2033

RunLoop.Append could block indefinitely when racing with cancellation of a waiting RunLoop.Exec.

Append changes the state from StateWaiting to StateIdle under the mutex, then sends a notification through the
unbuffered ready channel after releasing the mutex. If Exec selected ctx.Done() and returned before receiving that
notification, the Append caller was left blocked. When invoked from an async batch response callback, this could stop
the batch receive loop from retiring the request and processing later responses on the same stream.

Changes:

• Make the cancellation path distinguish between a run loop that is still waiting and one for which an Append has
  already committed to sending a notification.
• Consume the committed notification before returning from Exec, ensuring the notifying Append can complete.
• Document the notification handshake and its single-Exec safety invariant.
• Add regression coverage for the cancellation race, queued-task preservation, and subsequent Exec behavior.
• Make the concurrent Exec test deterministic by synchronizing on the first executor entering StateRunning.

Summary by CodeRabbit

• Bug Fixes
  • Improved reliability when task execution is canceled while new work is being added. Pending tasks remain available to run, and appending work no longer risks leaving execution waiting indefinitely.
  • Clarified behavior when multiple execution attempts overlap: only the attempt with available work succeeds; the other returns an error.

[coderabbitai]

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Advanced

Run ID: 14efbf30-28a6-4498-8edd-11c407150079

📥 Commits

Reviewing files that changed from the base of the PR and between 6e3fd8a and 263c82e.

📒 Files selected for processing (2)

• util/async/runloop.go
• util/async/runloop_test.go

Included review availability: This review used your included allowance. Your plan provides up to 2 included reviews per hour; 0 remain after this review.

---

📝 Walkthrough

Walkthrough

Exec now handles the pending notification when cancellation races with Append. Tests cover this race and concurrent Exec calls.

Changes

RunLoop synchronization

Layer / File(s)	Summary
Cancellation and notification handshake util/async/runloop.go	When cancellation occurs, Exec resets the state only if it is still StateWaiting. If Append has changed the state to StateIdle, Exec consumes the pending ready notification before returning the context error.
RunLoop concurrency tests util/async/runloop_test.go	A repeated race test checks that Append completes and its task remains runnable after Exec returns context.Canceled. The concurrent Exec test uses channels to verify that the second call returns an error with zero tasks while the first succeeds with one.

Priority: ➖ Normal

Estimated code review effort: 3 (Moderate) | ~20 minutes

Change: Bug fix · Severity of issue fixed: Medium

Merge Risk: ⚪ Minimal · up to 263c8

The cancellation fix is mergeable after normal checks.

Security Architecture Review

Security architecture risk: 🔵 Low · up to 263c8

The change addresses a cancellation race without changing who may submit or execute callbacks. The main remaining uncertainty is the behavior of callers outside the inspected code.

Retained concerns
No architecture-level concerns identified.

Security review details

Security Blast Radius

• inferred — The affected path is per-RunLoop callback scheduling, with a potential downstream availability effect on later responses sharing a batch receive stream. The inspected change does not broaden callback authority or establish tenant-wide exposure.

Trust Boundaries and Controls

• observed — A batch response is passed to its callback only when the entry is not marked canceled; the RunLoop change does not remove that check or execute the callback on cancellation.

Resilience and Maintainability Implications

• observed — The notification drain addresses the stranded-sender failure path while preserving queued tasks for a later Exec; cancellation during task execution likewise returns remaining tasks to the queue.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 3 functions across 2 files.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main change: preventing Append from blocking when Exec is canceled.
Linked Issues check	✅ Passed	Issue #2033 is closed and supplies historical context only. Per the assessment rules, no linked-issue coding requirements apply. The reviewed changes address the historical RunLoop.Append cancellati…
Out of Scope Changes check	✅ Passed	The changes stay within the stated scope. util/async/runloop.go changes the cancellation and notification handshake. util/async/runloop_test.go adds race regression coverage and makes the concurre…

• Fix all pre-merge checks with AI

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[ti-chi-bot]

@wfxr: adding LGTM is restricted to approvers and reviewers in OWNERS files.

Details

In response to this:

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[ti-chi-bot]

[LGTM Timeline notifier]

Timeline:

• 2026-09-29 03:44:11.45349957 +0000 UTC m=+681176.678720667: ☑️ agreed by cfzjywxk.
• 2026-09-29 03:48:32.073429932 +0000 UTC m=+681437.298651029: ☑️ agreed by you06.

[ti-chi-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: cfzjywxk, lcwangchao, wfxr, you06

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [cfzjywxk,you06]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[lcwangchao]

/retest