Add employee home and work address update commands - #151
Conversation
Both PUTs are keyed on the address UUID and require an optimistic- concurrency version. The version is auto-fetched by default (with a --record-version override), reusing the shared version helper so the behavior matches the raw api-request path. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: Austin Shieh <austin.shieh@gusto.com>
| }, | ||
| }; | ||
| } | ||
| const response = await resolved.ctx.client.request("PUT", path, injected.body); |
There was a problem hiding this comment.
putResourceWithVersion's try/catch wraps both the version GET and the PUT, so a failed version fetch, a 409/412 version conflict on the PUT, and a random network blip on the PUT all collapse into the same generic toResult(err). For a write, the version-conflict case especially deserves its own signal — that's the entire reason this function does a GET-then-PUT. There's also no test that makes either call in this block fail, so a regression here wouldn't get caught.
| if (!injected.ok) { | ||
| return { | ||
| ok: false, | ||
| exitCode: ExitCode.Validation, |
There was a problem hiding this comment.
version_unresolved returns ExitCode.Validation (7), but it's not a caller-input problem — it's the server returning a resource that's missing version, which reads more like ExitCode.Blocked (8), the same code the confirmation gate uses for "can't proceed as-is." A script/agent branching on exit code to tell "fix your flags" from "not your fault" would misclassify this one.
2 participants
Summary
employee update-home-addressandemployee update-work-addresswrite commands, PUTting to/v1/home_addresses/{uuid}and/v1/work_addresses/{uuid}.--record-versionis supplied.putResourceWithVersionhelper inapi-context.tsso future versioned PUT commands reuse the same version handling, confirm gate, and dry-run behavior.Linked issue
None.
Test plan
bun run test:allpasses locally--agentand--humanoutput verified where touchedDCO
git commit -s) per the DCO