follow bullmq docs for connection#57
Conversation
|
Warning Review limit reached
More reviews will be available in 42 minutes and 54 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThis PR adds graceful shutdown handling to the Nuxt processor module. The ChangesWorker Shutdown Integration
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related PRs
Suggested labels
Poem
🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 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 |
There was a problem hiding this comment.
🧹 Nitpick comments (1)
src/utils/generate-workers-index-wrapper.ts (1)
14-14: ⚡ Quick winForced stop has no timeout — a hung
app.stop({ force: true })blocks exit indefinitely.The graceful timeout fires correctly, but the fallback
await app.stop({ force: true })is itself unbounded. Sinceprocess.exitis only scheduled in thefinallyblock, it never runs if the forced stop hangs, defeating the purpose of the shutdown deadline. Consider an independent hard-exit safety timer that fires regardless of where the stop logic is stuck.♻️ Sketch: independent hard-exit safety net
- + `const shutdown = async (signal) => { if (shuttingDown) return; shuttingDown = true; let exitCode = 0; try { logger.info(... + + `const shutdown = async (signal) => { if (shuttingDown) return; shuttingDown = true; let exitCode = 0; const hardExit = setTimeout(() => process.exit(1), SHUTDOWN_TIMEOUT_MS * 2); if (typeof hardExit.unref === 'function') hardExit.unref(); try { logger.info(...(Clear
hardExitin thefinallybefore scheduling the normal exit.)Also note the
Promise.racetimeout timer is never cleared and the originalapp.stop()promise is left orphaned after a timeout, which can surface as an unhandled rejection.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/utils/generate-workers-index-wrapper.ts` at line 14, The shutdown handler (shutdown) currently leaves the forced app.stop({ force: true }) unbounded and never clears the Promise.race timeout, so add an independent hard-exit safety timer (e.g., HARD_EXIT_TIMEOUT_MS) started at shutdown start that will call process.exit(1) if any part of shutdown hangs; wrap the forced stop call inside a Promise.race with a short timeout and clear that timeout when stop resolves to avoid orphaned timers, also clear the initial graceful timeout timer created for Promise.race([app.stop(), timeout]) so the original app.stop() promise isn't orphaned, and finally ensure you clear the hard-exit timer in the finally block before scheduling the normal process.exit(exitCode); refer to shutdown, app.stop, SHUTDOWN_TIMEOUT_MS and the new hard-exit timer symbol when making these changes.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@src/utils/generate-workers-index-wrapper.ts`:
- Line 14: The shutdown handler (shutdown) currently leaves the forced
app.stop({ force: true }) unbounded and never clears the Promise.race timeout,
so add an independent hard-exit safety timer (e.g., HARD_EXIT_TIMEOUT_MS)
started at shutdown start that will call process.exit(1) if any part of shutdown
hangs; wrap the forced stop call inside a Promise.race with a short timeout and
clear that timeout when stop resolves to avoid orphaned timers, also clear the
initial graceful timeout timer created for Promise.race([app.stop(), timeout])
so the original app.stop() promise isn't orphaned, and finally ensure you clear
the hard-exit timer in the finally block before scheduling the normal
process.exit(exitCode); refer to shutdown, app.stop, SHUTDOWN_TIMEOUT_MS and the
new hard-exit timer symbol when making these changes.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 4b839170-bb7a-4b22-9181-f3a6d23bef53
⛔ Files ignored due to path filters (2)
package-lock.jsonis excluded by!**/package-lock.jsonspec/utils/__snapshots__/generate-workers-entry-content.spec.ts.snapis excluded by!**/*.snap
📒 Files selected for processing (16)
.cursor/mcp.jsonchangelog.mddocs/api.mddocs/redis.mdspec/runtime/handlers/defineQueue.spec.tsspec/runtime/handlers/defineWorker.spec.tsspec/runtime/plugins/close-processor.spec.tsspec/runtime/utils/workers.spec.tsspec/utils/generate-workers-entry-content.spec.tsspec/utils/generate-workers-index-wrapper.spec.tssrc/module.tssrc/runtime/server/plugins/close-processor.tssrc/runtime/server/utils/index.tssrc/runtime/server/utils/workers.tssrc/utils/generate-workers-entry-content.tssrc/utils/generate-workers-index-wrapper.ts
Summary
Briefly describe what this PR does and why.
Changes
How to Test
Screenshots (optional)
If applicable, add screenshots or recordings.
Linked Issues
Closes #
Checklist
npm run cipasses (ornpm run lintandnpm testat minimum)