---
id: "bug-1854"
status: "fixed"
status_updated: "2026-09-25"
status_note: "663ea63c"
component: "scheduler"
severity: "unknown"
timestamp: "2026-09-24T08:35:00Z"
files: ["src/scheduler/src/scheduler.c"]
tags: ["scheduler", "config-push", "rejoin", "resources", "log-noise"]
related: []
fix_commits: ["663ea63c"]
legacy: true
gitea_issue: 275
gitea_synced_status: "fixed"
gitea_synced_hash: "2c54c07e9725"
---

# bug-1854: Every HA soak run logs 'ERROR [sched_init_resources] sched_init_resources add resource <name>…

## Description
OPEN, NOT FIXED, low priority. Every HA soak run logs 'ERROR [sched_init_resources] sched_init_resources add resource <name> failed' for EVERY configured resource (~33 lines), once per scheduler process, ~30s after it joined -- i.e. when a primary failover makes the scheduler re-join and the controller re-pushes its config (231/264/429 lines in 3 soak runs today). Scheduling is unaffected in those runs (all soaks PASS, replay parity 0 mismatches).

## Environment
_Not recorded (migrated from buglog.json)._

## Reproduction
_Not recorded (migrated from buglog.json)._

## Root cause
sched_init_config() is written as a first-time initializer but runs on every config push (sched_apply_pending_config, including each rejoin's push). sched_init_resources() calls makeResource() for each config->resources[i], which fails when the name is already registered in core.resmgr (key_add of an existing key) and only logs. Consequences: (1) ERROR log noise on every rejoin; (2) latent: a rejoin/upgrade config push that CHANGES a resource definition (flags, valtype, order) never updates the scheduler's copy. Pre-existing -- the same call ran on the handler thread before bug-1846's deferral; not introduced by it. sched_init_queues() re-adding queues on each push is worth checking under the same lens.

## Fix
NOT FIXED. Candidate: on an existing name, update the registered xce_resource_t in place (or treat identical definitions as a no-op and log at DEBUG), mirroring core_events.c's core_upsert_* upsert posture for RESOURCES_PUSH; decide separately whether a changed definition needs picker/accounting refresh.

UPDATE (2026-09-25): 2026-09-25: same defect also at the core CONFIG_PUSH path -- core_events.c core_apply_config_resources() calls makeResource() per pushed resource; makeResource_() (lib/resobj.c) returns NULL/EEXIST for any already-registered name and the caller logs ERROR 'core_apply_config_resources add resource <name> failed'. Seen as 33 ERROR lines in data/scheduler-replay-20260925-133708.replay (sim --sim-verify, b63bb581): the scheduler rejoined at 13:39:27 and the controller re-pushed CONFIG (plus WORKERS/JOB_PUSH) onto a core whose resources were already registered. Verify 0 mismatches, all 60 jobs DONE -- noise only in that run. A fix must cover both sites (sched_init_resources and core_apply_config_resources): identical definition -> no-op at DEBUG; changed definition -> decide update-in-place vs loud WARN.

## Verification
_Not recorded (migrated from buglog.json)._

## References
- Gitea: #275