1.9 KiB
| id | status | status_updated | status_note | component | severity | timestamp | last_seen | occurrences | files | tags | related | fix_commits | legacy | gitea_issue | gitea_synced_status | gitea_synced_hash | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| bug-1712 | fixed | 2026-09-28 | controller | unknown | 2026-08-26T09:32:18Z | 2026-09-19T09:00:00Z | 1 |
|
|
|
|
true | 306 | fixed | 4bf952242b86 |
bug-1712: cmd_resupdate: a duplicate -v for the same pending resource (resupdate -n slots -v 4 -v 8)…
Description
cmd_resupdate: a duplicate -v for the same pending resource (resupdate -n slots -v 4 -v 8) prints the misleading message "ignore res value `%s' as no res name found" even though a resource name WAS found -- the real problem is a value is already pending for it, not a missing name.
Environment
Not recorded (migrated from buglog.json).
Reproduction
Not recorded (migrated from buglog.json).
Root cause
The else-branch of the -v case handles two distinct situations (no preceding -n at all, vs. a duplicate -v for an already-named pending resource) with one shared, incorrectly-worded message.
Fix
The -v branch now tells the two cases apart: no preceding -n keeps "no res name found"; a second value for the same resource prints "ignoring duplicate value 8' for res slots' (it already has value `4')".
Verification
- Test: test_resupdate_duplicate_value_named_correctly in src/harness/testsuite/test_test_cli.c: RED before the fix ("no res name found"), GREEN after
- Suites: harness 6/6 (asan): harness_unit_test 141/0, cmdutil 14/0, resval_typeresolve 7/0, joblist_display 22/0, join_worker_args 7/0, listrow_json 12/0
- Live: n/a; xce_test is a client tool and every case above runs without a controller
References
- Related: bug-1706, bug-1707