docs(buglog): record Gitea sync for bug-1958..bug-1967

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

2026-10-10 10:51:33 +00:00

2.7 KiB

Raw Blame History

status

status_updated

status_note

component

severity

timestamp

last_seen

occurrences

files

bug-1967: xce_scheduler ignores limit changes in a re-pushed config: seeding stops at the first existing name

Description

Observed: (source reading, 2026-10-10; reported by the bug-1964 fix) limit_seed_config_impl() (src/scheduler/src/plugins/limit.c) builds each configured limit and adds it with key_add(privdata->limits, limit->name, ...), returning at the first failure:

rc = key_add(privdata->limits, (void*)limit->name, (void*)limit);
...
if (rc < 0) {
    ...            /* bug-1685: the kvmgr already freed `limit` */
    return rc;
}

On a later config push (live config upgrade, or a mid-replay CONFIG_PUSH in the simulator since bug-1964) every limit name already exists, so the first key_add fails with -EEXIST: no limit is updated, a limit whose value or scope changed keeps its old definition, and limits listed after an existing one are never added.

Expected: a config push replaces the configured limits: changed limits take their new definition, new ones are added, removed ones disappear (their usage instances handled consistently). Impact: wrong result: limit changes made by a live config upgrade do not take effect until the scheduler restarts; live and simulator agree (both wrong). Found by: fix of bug-1964 (sim limit config push), 2026-10-10.

Environment

OS: no /etc/os-release; Docker container; NixOS kernel; kernel Linux 6.18.33 x86_64
libc: glibc 2.42-47 (interpreter /nix/store/wb6rhpznjfczwlwx23zmdrrw74bayxw4-glibc-2.42-47/lib/ld-linux-x86-64.so.2)
Toolchain: gcc (GCC) 15.2.0, meson 1.9.1
Build: asan (xce.build)
Code: scheduler-framework @ f3898457-dirty
Deployment: any scheduler (live config upgrade) and xce_scheduler --sim replays with a config push

Reproduction

Configure limit L (value 4) and start the scheduler.
Push a config where L has value 2 and a new limit M follows it.
The scheduler still enforces L = 4 and has no M (REPL info limit all).

Frequency: deterministic (code path)
Evidence: the code quoted in Description; no logs kept.

Root cause

TODO: required for fixed/partial

Fix