---
id: "bug-1570"
status: "fixed"
status_updated: "2026-09-24"
status_note: ""
component: "controller"
severity: "unknown"
timestamp: "2026-08-17T23:45:00Z"
last_seen: "2026-09-19T09:00:00Z"
occurrences: 1
files: ["src/controller/testsuite/test.c"]
tags: ["resupdate", "cmd_resupdate", "getopt", "duplicate-flag", "last-write-wins", "resource-value-verification", "task-2.1", "round-2-remediation"]
related: ["bug-1569"]
legacy: true
---

# bug-1570: resource-value-verification task 2.1 round-1 REJECTED: `resupdate -n mem -v 5 -v 8` silently…

## Description
resource-value-verification task 2.1 round-1 REJECTED: `resupdate -n mem -v 5 -v 8` silently overwrote to 8 (last-write-wins) instead of rejecting the duplicate -v and keeping the first value 5

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

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

## Root cause
cmd_resupdate()'s deferred-finalization refactor (needed so a trailing -t can still apply to its pending -n/-v pair) rewrote the 'v' case to `if (resname != NULL) { resval_str = optarg; }` -- it dropped the pre-existing guard that rejected a second -v for the same pending -n. Baseline (pre-task-2.1, git show 98b8c34b^) fired set_resval() immediately on -v and reset resname=NULL, so a second -v naturally hit the 'no res name found' else-branch; the deferred model keeps resname non-NULL across multiple -v's, so the missing resval_str==NULL check let the second -v silently clobber the first.

## Fix
Changed the 'v' case guard to `if (resname != NULL && resval_str == NULL)` -- only accept a value into the pending slot if a name is pending AND no value has already been accepted for it; a duplicate -v now prints the same `ignore res value \`%s' as no res name found` warning and the first value is kept. Verified via full case-by-case trace against the git-show baseline (duplicate -v, two full -n/-v pairs, -n flushing a valueless prior -n, stray -v with no -n, trailing bare -n, and the new -t override case) plus a live single-node controller smoke test: `resupdate -n mem -v 5 -v 8` on a real joined worker prints the ignore-warning for `8` and `resval -n mem -m localhost` confirms the stored value is 5.000000, not 8.

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

## References
- Related: bug-1569