fix: dynamic-code shutdown no longer waits forever on stuck user code

[hatayama]

Summary

• ShutdownAsync now waits at most 5s (ctor-overridable) for in-flight work to finish disposing resources.
• If user code ignores cancellation past that bound, waiters unblock with a warning and pool dispose stays deferred to the late finally.

User Impact

• Before: Server/runtime shutdown could hang indefinitely while execute-dynamic-code user code ignored cancellation.
• After: Shutdown drain always completes within the timeout. Domain-reload still does not wait for drain (unchanged).

Changes

• Option A: timeout → TrySetResult(true) + warning; no force-dispose under a running action.
• LogWarning injected via DynamicCodeExecutionSchedulerHooks; facade wires Debug.LogWarning (scheduler stays pure C#).
• Cancelable Task.Delay so early completion does not leave a timeout timer running.
• Pure unit tests for idle, cooperative cancel, and ignore-cancel + late finally idempotency (no EditMode E2E).

Refs

• Spec §3 PR 3-2
• Design: /tmp/claude-shared/pr-3-2-design.md
• Answers: /tmp/claude-shared/pr-3-2-review-answers.md

Verification

• dotnet test tests/DynamicCodeExecutionScheduler.UnitTests (9/9)
• uloop compile 0/0
• EditMode domain-reload drain test still passes

Made with Cursor

[coderabbitai]

Warning

Review limit reached

@hatayama, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 31 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 65565f8d-4d83-4f8f-8e69-fbdf4d45d344

📥 Commits

Reviewing files that changed from the base of the PR and between 343e478 and a5994f2.

📒 Files selected for processing (4)

• Packages/src/Editor/FirstPartyTools/ExecuteDynamicCode/Execution/DynamicCodeExecutionFacade.cs
• Packages/src/Editor/FirstPartyTools/ExecuteDynamicCode/Execution/DynamicCodeExecutionScheduler.cs
• Packages/src/Editor/FirstPartyTools/ExecuteDynamicCode/Execution/DynamicCodeExecutionSchedulerHooks.cs
• tests/DynamicCodeExecutionScheduler.UnitTests/DynamicCodeExecutionSchedulerTests.cs

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/dynamic-code-shutdown-timeout

---

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.}

[hatayama]

LGTM (reviewer: Fable). Matches the agreed Option A design: bounded WhenAny wait with a cancelable Delay (timer cleaned up on the normal path), timeout completes the shutdown TCS via TrySetResult(true) while pool dispose stays deferred to the running action's finally, warning goes through an injected hooks sink so the scheduler stays Unity-free (Debug.LogWarning wired at the facade edge), and the domain-reload fire-and-forget path is untouched. The three tests cover idle, cooperative-cancel, and ignore-cancel timeout including the deferred single dispose and re-entrant ShutdownAsync. Verified locally: 9/9 green at a5994f2. One informational note (no change needed): a canceled Task.Delay does not feed UnobservedTaskException — only faulted tasks do — so the ContinueWith observer is harmless but not strictly required.