Rongsong Shen
cc7e99c2f7
persist_apply_pump_run() no longer discards apply_committed_entry()'s return value. On a negative rc for any WAL type (not just the new array type), the walk halts at that LSN — no last_applied_lsn advance, no pending-apply hand-off — logs a loud error, and retries from the same position on the next kick, mirroring the existing apply_pump_read_entry failure branch's shape. Investigated whether this newly turns the pre-existing job-fact -ENOENT path into a permanent-wedge hazard: it does not, since c->jobmgr never deletes entries and facts are only ever applied after their causally-prior submit already succeeded, so a live -ENOENT there can only mean genuine divergence — halting is the correct behavior. Task 4.1 of job-array-single-wal-record (Requirement 9.4). |
||
|---|---|---|
| .. | ||
| settings | ||
| specs | ||
| steering | ||