-
Notifications
You must be signed in to change notification settings - Fork 173
fix(worker): Fix issues with gracefully shutting down #612
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the WalkthroughThe pull request introduces graceful shutdown handling for job queues, implements job state validation before execution, enriches job payloads with metadata, adds a reusable signal listener for shutdown orchestration, and updates method signatures to pass Changes
Sequence Diagram(s)sequenceDiagram
participant Worker
participant JobQueue
participant DB as Prisma/Redis
participant Handler
rect rgb(200, 220, 255)
note over Worker: Job Lifecycle with Graceful Timeout
end
Worker->>Worker: runJob called
Worker->>DB: Fetch current job status
DB-->>Worker: Job status
alt Status is PENDING or IN_PROGRESS
Worker->>Worker: Execute job
alt Normal Completion
Worker->>Handler: Job success
else Graceful Timeout
Handler->>Worker: onJobGracefulTimeout
Worker->>DB: Mark job as FAILED
Worker->>Handler: Update metrics & log
end
else Status is other
Worker->>Handler: Throw error (skip invalid state)
end
sequenceDiagram
participant System
participant Index as index.ts
participant Managers as ConnectionManager<br/>RepoIndexManager
participant Services as Prisma<br/>Redis<br/>API<br/>Posthog
participant Signals
rect rgb(255, 220, 200)
note over System: Graceful Shutdown Flow
end
Signals->>Index: SIGTERM/SIGINT/etc.
Index->>Index: listenToShutdownSignals
Index->>Managers: dispose() each manager
par Manager Cleanup
Managers->>Managers: Worker.gracefulStop(timeout)
Managers->>Services: Delete Redis lock keys
Managers->>Managers: Log lock release
end
Index->>Services: Disconnect each service
Services-->>Index: Disconnected
Index->>Index: Exit gracefully
Index->>Signals: Remove handlers
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Areas requiring extra attention:
Possibly related PRs
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
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 |
This comment has been minimized.
This comment has been minimized.
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
packages/backend/src/connectionManager.ts(9 hunks)packages/backend/src/constants.ts(1 hunks)packages/backend/src/index.ts(3 hunks)packages/backend/src/repoCompileUtils.ts(1 hunks)packages/backend/src/repoIndexManager.ts(6 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
**/*
📄 CodeRabbit inference engine (.cursor/rules/style.mdc)
Filenames should always be camelCase. Exception: if there are filenames in the same directory with a format other than camelCase, use that format to keep things consistent.
Files:
packages/backend/src/constants.tspackages/backend/src/repoCompileUtils.tspackages/backend/src/index.tspackages/backend/src/repoIndexManager.tspackages/backend/src/connectionManager.ts
This PR resolves a couple of issues:
gracefulTimeoutparam (defaults 30 seconds). If there are any jobs still in progress after that duration, there is a bug in groupmq where the job's group lock will not be released (see [bug] Group lock is not released after graceful shutdown, resulting in stalling jobs Openpanel-dev/groupmq#8). This resulted in jobs (especially long running connection jobs) being left in PENDING or IN_PROGRESS indefinitely, and new jobs not being queued until the timeout expires. The current workaround is to explicitly free the locks when calling dispose.index.tsSummary by CodeRabbit
Release Notes
Bug Fixes
Improvements