---
id: "bug-1712"
status: "fixed"
status_updated: "2026-09-28"
status_note: ""
component: "controller"
severity: "unknown"
timestamp: "2026-08-26T09:32:18Z"
last_seen: "2026-09-19T09:00:00Z"
occurrences: 1
files: ["src/harness/test.c"]
tags: ["controller", "testsuite", "xce_test", "cmd_resupdate", "misleading-error-message", "cli-ux-audit"]
related: ["bug-1706", "bug-1707"]
fix_commits: ["da1a663f"]
legacy: true
gitea_issue: 306
gitea_synced_status: "fixed"
gitea_synced_hash: "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