docs(buglog): bug-1967, bug-1955, bug-1936 fixed; log bug-1968 (restart drops options)

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

.wolf/bugs/bug-1967.md

@@ -1,8 +1,8 @@
 ---
 id: "bug-1967"
-status: "open"
+status: "fixed"
 status_updated: "2026-10-10"
-status_note: "newly logged"
+status_note: ""
 component: "scheduler"
 severity: "wrong-result"
 timestamp: "2026-10-10T10:47:20Z"
@@ -11,6 +11,7 @@ occurrences: 1
 files: ["src/scheduler/src/plugins/limit.c"]
 tags: ["scheduler", "limit", "config"]
 related: ["bug-1964", "bug-1685"]
+fix_commits: ["8faf5961"]
 gitea_issue: 398
 gitea_synced_status: "open"
 gitea_synced_hash: "1b09440ec632"
@@ -59,15 +60,21 @@ wrong).
 - Frequency: deterministic (code path)
 - Evidence: the code quoted in Description; no logs kept.
 ## Root cause
-TODO: required for fixed/partial
+`limit_seed_config_impl()` (`src/scheduler/src/plugins/limit.c`) added each pushed limit to the existing `privdata->limits` table and returned at the first `key_add()` failure; kvmgr has no delete, so on any re-push the first already-present name failed with `-EEXIST`: old definitions stayed, later new limits were never added and removed ones never dropped. Live config upgrade (`limit_update_config`) and the sim's CONFIG_PUSH (`plugin_config_update_core`, bug-1964) share this path. Pre-existing since limits were seeded from config.
 
 ## Fix
-TODO: required for fixed/partial
+New `src/scheduler/src/plugins/limit_config.c` `limit_replace_config()` (private data type moved to `limit_internal.h`; `limit.c` was at its line cap):
+- builds the whole new limit set in a fresh table, all-or-nothing: a build failure or duplicate name discards it and keeps the previous limits and instances (bug-1685 ownership kept: a `key_add`-rejected limit is not freed twice; a `build_limit` failure now frees the half-built limit);
+- carries usage instances across: a limit kept under the same name with the same per-user/queue/project/host scoping, resource and percent flag keeps its instances, rebound to the new definition (usage lives in the resource manager's vres, untouched); instances of removed or re-scoped limits are dropped and re-created on the next match;
+- swaps the tables, then frees old instances, then old limits.
+Jobs' `glimits`/`hlimits` may briefly hold stale instance pointers; they are rebuilt by `limit_job_election()` before any read (pushes apply between rounds and bump `configver`), documented in the file header. Limits/instances are not in the scheduler snapshot (it reseeds from config), so no save/restore change. Behaviour change: a config containing one bad limit now yields no new limits (the previous set stays) instead of keeping the limits listed before the bad one.
 
 ## Verification
-- Test: TODO: name + file; RED before the fix, GREEN after
-- Suites: TODO: suite results and build profile
-- Live: TODO: soak/deploy run, or n/a and why
+- Test: `test_repush_changed_value_takes_effect`, `test_repush_adds_new_limit_after_existing`, `test_repush_removes_dropped_limit`, `test_repush_rebinds_kept_and_drops_removed_instances`, `test_repush_scope_change_drops_instance`, `test_repush_failure_keeps_previous_set` (`src/scheduler/testsuite/test_limit_plugin.c`): RED `test_limit_plugin.c:595:test_repush_changed_value_takes_effect:FAIL: Expected 0 Was -17` (same at :614, :636, :669, :702), GREEN after. `test_repl_limit_table.c` now pushes limitA+limitB in one config (it relied on the bug).
+- Suites: `xce-build.sh all asan xce.build --incremental` on the merged branch (scheduler-framework @ edad8c73), 2026-10-10: all C suites Ok 158 / Fail 0, frontend Go unit tests (apiserver + xcecli) ok; apiserver `CGO_ENABLED=0 go test ./...` (all packages) ok
+- Live: n/a: unit-level only; no live config-upgrade run (follow-up: push a changed limit to a running scheduler and check REPL `info limit all`)
 
 ## References
-- Related: none
+- Fix commit: `8faf5961` (worktree original `9bd927d8`)
+- Related: bug-1964, bug-1685
+