[cuebot] Memory pool reserved doesn't return to 0 after a frame is finished

[sericicole]

Describe the bug
After a frame finish, instead of returning to 0, the memory reserved field stays at 6144. This number increases proportionally to the number of frames launched.

At some point, this value was 12288, or was influenced by the minimum memory that can be set in a service, but we cannot reproduce this behaviour. For now the value stays at 6144, even on different hosts.

To Reproduce
Submit this job and verify the int_memory_idle in the database or the memory attributes of your host in the UI

import outline
import outline.modules.shell

# Create a new job
job = outline.Outline(
    name="my-first-job",
    shot="tutorial", 
    show="learning",
    user="student"
)

# Add a simple layer that prints frame numbers
test_layer = outline.modules.shell.Shell(
    name="test-layer",
    command=["echo", "Processing frame #IFRAME#", "&&", "sleep", "5"],
    range="1-1"
)

# Add the layer to the job
job.add_layer(test_layer)

# Submit the job
print("Submitting job:", job.get_name())
outline.cuerun.launch(job, use_pycuerun=False)
print("Job submitted successfully!")

Expected behavior
The idle memory of an host should return to is highest level after a frame finish.

Screenshots

Version Number
1.17

[sericicole]

This fix : 7e268fb

doesn't seem to prevent the memory from being reset. It goes back to 12288 for now. I suppose this drift value is random.
Every 10 minutes, it resets according to the fix.

The problem appears at the very first job we launch.

If we use dispatcher.turn_off_booking=false and stop the Scheduler, the memory gets correctly reinitialized after a frame is finished.

[DiegoTavares]

That's really odd. We don't see it happening so often in our case and not so consistently.

[DiegoTavares]

I've having a hard time wrapping my head around the cause for this issue. Here's an analysis from Claude that gives a probable cause, but I find it hard to believe it would be happing as frequently as you reported if that was the case:

Most Likely Specific Mechanism

The 120-second grace period at HostReportHandler.java:1010 is the key enabler. For short-lived frames (like the 5-second repro), frames bypass verifyRunningProc entirely. This means:

1. Frame completes, stopFrame sets proc.pk_frame = NULL
2. HostReport arrives, frame is in grace period → added to runningFrames without verification
3. handleMemoryReservations calls increaseReservedMemory(proc, frame.getRss())
4. The proc's pk_frame = NULL, but the increaseReservedMemory query uses pk_proc (not pk_frame), so it succeeds
5. Trigger fires: int_mem_idle -= (RSS - old_reserved)
6. Then handlePostFrameCompleteOperations runs, deletes proc, procDestroyed adds back the INCREASED value
7. Math balances: -old + -(RSS - old) + RSS = 0 ✓

Even with this race, the math should balance. The remaining possibility is that increaseReservedMemory fires on a proc that's simultaneously being deleted, and the trigger's UPDATE host and procDestroyed's UPDATE host execute against the same starting int_mem_idle value due to a PostgreSQL MVCC anomaly — but
PostgreSQL's row-level locking prevents this.

Conclusion

After exhaustive analysis, the drift appears to stem from a narrow concurrency window where:

1. A HostReport processes a just-completed frame (grace period bypasses verification)
2. increaseReservedMemory modifies proc.int_mem_reserved and triggers int_mem_idle reduction
3. A new dispatch is initiated using a stale DispatchHost object
4. The concurrent updates to host.int_mem_idle from the trigger, the new proc's procCreated, and the old proc's procDestroyed create a transient inconsistency that the periodic reconciliation corrects

The 120-second grace period (FRAME_VERIFICATION_GRACE_PERIOD_SECONDS = 120 at line 986) is the primary enabler — it allows completed frames to be processed as if still running, which triggers increaseReservedMemory on a proc that's about to be deleted.

The fact that disabling booking prevents the drift supports this: without booking, there's no DispatchBookHost from the HostReport, and the handlePostFrameCompleteOperations path alone handles cleanup correctly.

Can you share more details about your setup and cuebot configurations that might differ from the default?

[sericicole]

I think the bug is in the scheduler in proc_dao.rs

If i divide memory_reserved by 1000 (KB) instead of 1024 (KIB), i don't have the drift anymore.

524288000/1024 = 512000. 524288 - 512000 = 12288 ^_^

The value is divide by KB in frame_dao.rs

For now, I'm not sure if other values have to be switched to KB.

[sericicole]

I will test this change more tomorrow :)
For both cuebot and scheduler we use the config files provided by the repository. I don’t think the small changes we made would explain why we had this drift more often than spi.