Repository navigation
[cuebot] Prevent Lost procs from being deferred forever - #2508
Merged
DiegoTavares merged 1 commit intoAug 12, 2026
Merged
DiegoTavares merged 1 commit into
DiegoTavares merged 1 commit into
Conversation
Follow-up to AcademySoftwareFoundation#2506: a restarted RQD answers kill-before-release with NOT_FOUND, which was wrapped as a failure, so lostProc deferred provably dead frames indefinitely and re-logged the "Deferring release of lost proc" WARN every 30s. - RqdClientGrpc.killFrame now treats NOT_FOUND as confirmed-stopped (matching isFrameRunning); only unknown outcomes throw RqdClientException. - Bound the deferral: after dispatcher.lost_proc_max_defer_ms (default 20 min) without a ping proving the frame alive, release the proc and fail the frame closed to DEAD (manual retry) instead of deferring again. Negative disables the bound. - Boot-time fence: a host whose reported boot time is later than the proc's dispatch (plus a clock-skew margin) cannot be running the frame, so release it to WAITING even when the kill cannot be delivered. - Orphaned-proc reaper: order candidates oldest-ping first (deterministic batch turnover) and make the batch size configurable (maintenance.orphaned_proc_batch_size, default 100) so unconfirmable procs cannot starve releasable orphans. New unit tests cover the fail-closed bound, the boot fence, and killFrame status classification against a real localhost gRPC server; DAO tests cover the new queries.
Contributor
📝 WalkthroughWalkthroughThe change adds proc ping and reboot checks, bounds deferred lost-proc handling, treats RQD ChangesProc recovery and maintenance
Estimated code review effort: 4 (Complex) | ~45 minutes Sequence Diagram(s)sequenceDiagram
participant DispatchSupportService
participant ProcDaoJdbc
participant RqdClientGrpc
DispatchSupportService->>ProcDaoJdbc: Check ping age and host reboot
DispatchSupportService->>RqdClientGrpc: Kill frame
RqdClientGrpc-->>DispatchSupportService: Return success, NOT_FOUND, or error
DispatchSupportService->>DispatchSupportService: Stop frame as WAITING or DEAD
Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
🧪 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 |
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 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.
Inline comments:
In `@cuebot/src/main/java/com/imageworks/spcue/dao/postgres/ProcDaoJdbc.java`:
- Around line 582-586: Update the orphan query’s ORDER BY clause in ProcDaoJdbc
to sort first by proc.ts_ping and then by proc.pk_proc, preserving oldest-first
ordering while making limited batches deterministic for equal timestamps.
In
`@cuebot/src/main/java/com/imageworks/spcue/service/MaintenanceManagerSupport.java`:
- Around line 206-208: Validate batchSize in checkHardwareState() before calling
procDao.findOrphanedVirtualProcs(); when maintenance.orphaned_proc_batch_size is
non-positive, replace it with DEFAULT_ORPHANED_PROC_BATCH_SIZE so the cleanup
query always receives a valid limit.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: b2f8c61b-17d0-4fe6-aa67-44fa3a27c6aa
📒 Files selected for processing (10)
cuebot/src/main/java/com/imageworks/spcue/dao/ProcDao.javacuebot/src/main/java/com/imageworks/spcue/dao/postgres/ProcDaoJdbc.javacuebot/src/main/java/com/imageworks/spcue/dispatcher/DispatchSupportService.javacuebot/src/main/java/com/imageworks/spcue/rqd/RqdClient.javacuebot/src/main/java/com/imageworks/spcue/rqd/RqdClientGrpc.javacuebot/src/main/java/com/imageworks/spcue/service/MaintenanceManagerSupport.javacuebot/src/main/resources/opencue.propertiescuebot/src/test/java/com/imageworks/spcue/test/dao/postgres/ProcDaoTests.javacuebot/src/test/java/com/imageworks/spcue/test/dispatcher/DispatchSupportServiceLostProcTests.javacuebot/src/test/java/com/imageworks/spcue/test/rqd/RqdClientGrpcTests.java
DiegoTavares
marked this pull request as ready for review
August 12, 2026 05:33
DiegoTavares
requested review from
lithorus and
ramonfigueiredo
as code owners
August 12, 2026 05:33
DiegoTavares
merged commit Aug 12, 2026
48a7b70
into
AcademySoftwareFoundation:master
23 of 25 checks passed
DiegoTavares
added a commit
that referenced
this pull request
Aug 26, 2026
Close the remaining free-then-rebook path that survived #2506/#2508: the generic launch rollback released the booking first (proc deleted, frame back to WAITING) and fired a best-effort kill whose failure was swallowed. When a launchFrame RPC fails on the Cuebot side after the request was delivered (deadline expired waiting for the response, connection dropped mid-call), the render is alive on the host, the kill fails on the same broken network, and the freed frame is instantly re-booked by another Cuebot -- each failed launch becomes a double-booking under RPC instability. - RqdClientGrpc.launchFrame classifies failures: transport-level codes (DEADLINE_EXCEEDED, UNAVAILABLE, CANCELLED, INTERNAL, DATA_LOSS) throw the new RqdLaunchUnknownOutcomeException; application-level responses (RQD rejects with ABORTED/FAILED_PRECONDITION/INVALID_ARGUMENT) prove the frame never started and keep the plain RqdClientException. - Both copies of the release-first rollback route unknown-outcome launch failures through DispatchSupport.resolveUnknownLaunchOutcome instead: CoreUnitDispatcher's DispatchFrameTemplate (the production dispatch path, used by dispatchHost and dispatchProcToJob) and AbstractDispatcher.dispatchProc/dispatchHost (the LocalDispatcher and RedirectManager paths). The legacy rollback is preserved for proven rejections. - resolveUnknownLaunchOutcome confirms before releasing anything: a frame confirmed running keeps its booking and finishes through its own frame complete report; a frame confirmed not running (two consecutive isFrameRunning polls within dispatcher.launch_confirm_budget_ms) is released for re-dispatch; anything unconfirmable keeps the booking (fail closed) and is reclaimed by the orphaned-proc reaper's own kill-and-confirm path. A non-positive budget restores the legacy behavior. - New counter cue_frame_launch_outcome_unknown_total{resolution} plus DispatchSupport.unknownLaunchOutcomes. Unit tests cover the status classification against a real localhost gRPC server, the resolver's four resolutions, and the rollback routing in both dispatcher rollback sites. ## LLM usage disclosure Claude Opus was used for implementing the fix and unit tests. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Prevented frames from being double-booked when launch results are uncertain. * Verified frame status before releasing bookings after uncertain launch failures. * Preserved rollback behavior for confirmed launch failures. * Prevented rollback from clearing frames belonging to newer dispatches. * **New Features** * Added configurable launch-outcome confirmation with a 20-second default window and 7-second polling interval. * Added Prometheus metrics for launches with unknown outcomes. * Improved monitoring and handling of uncertain launch failures. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
DiegoTavares
added a commit
to akheffache/OpenCue
that referenced
this pull request
Aug 28, 2026
Brings in AcademySoftwareFoundation#2473, AcademySoftwareFoundation#2497, AcademySoftwareFoundation#2501, AcademySoftwareFoundation#2502, AcademySoftwareFoundation#2504, AcademySoftwareFoundation#2506, AcademySoftwareFoundation#2508, AcademySoftwareFoundation#2510, AcademySoftwareFoundation#2511 and the cueweb dependency bumps. Conflict resolutions: - applicationContext-service.xml, FrameDao: keep both sides. - DispatchQuery: keep the branch's layer.pk_layer fix plus master's ts_start_after predicate. - RqdClientGrpc: master's split catch and unknown-outcome throw, keeping the branch's warn log of the underlying launch failure on both paths. - FrameCompleteHandler: master refactored the class into small methods, so the scheduler hooks were re-applied on top of the new structure rather than merged line by line. The drain path (resolveForDrain) now also runs master's orphan-finalize and run-ownership fences, and handleStaleCompletion delegates to handleStaleReport so scheduler-owned shows get the same duplicate check and re-read guard as legacy ones; its Scheduler call site passes the report. The bookingOff guards became isBookingOff() calls inside the extracted booking methods, and the per-frame OOM bump moved into retryFrameWithRaisedMemory. FrameCompleteHandlerOwnershipTests builds the handler from a bare Environment mock; the constructor now unboxes numeric properties, so the mock returns the supplied defaults. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0114CS5RrhDjTJse5faC4Pcb
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #2506: a restarted RQD answers kill-before-release with NOT_FOUND, which was wrapped as a failure, so lostProc deferred provably dead frames indefinitely and re-logged the "Deferring release of lost proc" WARN every 30s.
New unit tests cover the fail-closed bound, the boot fence, and killFrame status classification against a real localhost gRPC server; DAO tests cover the new queries.
LLM usage disclosure
Claude Opus was used for investigating the logs and implementing this fix.
Summary by CodeRabbit
Bug Fixes
Configuration