Bound the CI test step and drop the unusable dispatch guard - #1449
Conversation
within_dispatch_timeout could never fire. A stranded UDF dispatcher wedges the VM with the GVL held, so Thread#join's timeout never runs and flunk is unreachable — a regression hung the run exactly as it would have with no guard at all. Verified on the unfixed build: the wedged process also ignores SIGTERM, so plain `timeout` cannot reclaim it either. Put the bound where it can actually be enforced, as timeout-minutes on the Ubuntu and macOS test steps. The step is the part that can wedge; keeping it off the job clock leaves checkout, setup and the duckdb download out of the budget. The suite runs in ~50s locally, so 3 minutes is ample. Windows already bounds its test step through nick-fields/retry. Job-level timeout-minutes stays as the backstop. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughThe UDF error tests no longer use thread-based dispatch timeouts. The macOS and Ubuntu Ruby test steps now have three-minute CI timeouts with comments about potential callback hangs. ChangesUDF timeout handling
Merge Risk: ⚪ Minimal · up to The change bounds the CI test step and removes an ineffective test guard without introducing an actionable merge-blocking risk; it is merge-ready after normal checks and review. Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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. Comment |
Follow-up to #1448.
Problem
within_dispatch_timeout, added in #1448, cannot do what it claims. A stranded UDF dispatcher wedges the VM with the GVL held, soThread#join(timeout)never returns and theflunkafter it is unreachable — a regression hangs the run exactly as it would with no guard at all.Verified against the unfixed build (
mainbefore #1448): the NUL-message query strands the dispatcher and the next query never returns, atthreads=1and at default threads, with a 10-row table and with 300k rows. The wedged process also ignoresSIGTERM, so plaintimeoutcannot reclaim it — onlytimeout -s KILL.So the guard is a bound that looks like a bound and isn't, which is worse than none: the next person to break this trusts it and CI hangs anyway.
Change
Put the bound where it can actually be enforced —
timeout-minutes: 3on the test step intest_on_ubuntu.ymlandtest_on_macos.yml— and delete the guard.The step, not the job, because the test step is the only part that can wedge. Keeping it off the job clock leaves checkout,
setup-ruby, the MySQL service health-checks, a possible cold duckdb download andrake buildout of the budget; recent greenmainruns took 1m47s–3m30s end to end, so a 3-minute job cap would have failed two of the last five.test_on_windows.ymlneeds nothing — it already bounds its test step throughnick-fields/retrywithtimeout_minutes: 1.Job-level
timeout-minutes: 120stays as the backstop, since a wedged VM ignoring SIGTERM means the step kill wants something behind it.Verification
Against merged
main(4a0b3ed), extension rebuilt:test/duckdb_test/function_error_message_test.rb— 4 runs, 9 assertions, 0 failures, 0.21srubocop— no offenses52s against a 3-minute step bound is ~3.5x headroom.
🤖 Generated with Claude Code
Summary by CodeRabbit
Tests
Chores