fix(scheduler): record events before the core applies them (bug-1852)
The recorder encoded each controller event batch after xce_core_push_events() had applied it, and applying moves payload fields out of the events: a WORKERS_PUSH's resvals (core_apply_worker_resvals MOVE_PTR), a JOBS_PUSH's allocs, a JOB_RUSAGE's rusages, and a CONFIG_PUSH's shared resvals (sched_apply_pending_config recorded after sched_init_config). Recordings silently lost exactly those fields -- a worker's resval names were written with NULL values, so --sim-verify replayed "no slots" and turned 3 live DISPATCHes into PENDs. driver.c now records the batch before the push; the periodic in-stream SnapshotEntry moves out of sched_record_write_events() into new sched_record_checkpoint_after_apply(), called after the push so a checkpoint still reflects the events written ahead of it. The config push is likewise recorded before sched_init_config(). Regression test: test_recorded_workers_push_keeps_resval_values (RED: recorded value NULL; GREEN after). Periodic-checkpoint tests updated to the write-then-checkpoint contract. meson test 109/109; 25 live soak recordings replay with 0 mismatches. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
This commit is contained in:
parent
ca4db13a79
commit
9c02184fb4
10 changed files with 258 additions and 33 deletions
|
|
@ -280,6 +280,13 @@ int sched_record_write_events(xce_scheduler_t* sched, xce_core_event_t* events,
|
|||
return 0;
|
||||
}
|
||||
|
||||
/* bug-1852: driver.c now checkpoints separately, after applying a batch. */
|
||||
int sched_record_checkpoint_after_apply(xce_scheduler_t* sched)
|
||||
{
|
||||
(void)sched;
|
||||
return 0;
|
||||
}
|
||||
|
||||
/* sched_record_start/sched_record_stop (scheduler-core spec, task 9.4) --
|
||||
* driver.c's handle_deferred_admin_record() (new this task) calls both;
|
||||
* this file never enqueues an XCE_SCHED_OP_ADMIN_RECORD request, so
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue