Version: acp-cli 1.0.29
Repro:
- Hide an offering:
acp offering update --offering-id <id> --hidden → confirmed hidden.
- Later run any other update on the same offering, e.g.
acp offering update --offering-id <id> --subscription-ids "" (or a price/desc change) without passing --hidden.
- The offering becomes visible again —
isHidden silently resets to false.
Cause (observed): the update command appears to send a full offering object with defaults for unspecified fields rather than a partial patch, so any field not re-passed on the command line reverts to its default.
Impact: while a storefront is deliberately parked (e.g. pending fixes), any routine offering edit silently re-publishes it to buyers. We were bitten twice before adopting a "pass --hidden on every update" workaround.
Expected: unspecified fields should be left unchanged (PATCH semantics), or the CLI should warn that omitted fields will be reset.
🤖 Generated with Claude Code
Version: acp-cli 1.0.29
Repro:
acp offering update --offering-id <id> --hidden→ confirmed hidden.acp offering update --offering-id <id> --subscription-ids ""(or a price/desc change) without passing--hidden.isHiddensilently resets tofalse.Cause (observed): the update command appears to send a full offering object with defaults for unspecified fields rather than a partial patch, so any field not re-passed on the command line reverts to its default.
Impact: while a storefront is deliberately parked (e.g. pending fixes), any routine offering edit silently re-publishes it to buyers. We were bitten twice before adopting a "pass --hidden on every update" workaround.
Expected: unspecified fields should be left unchanged (PATCH semantics), or the CLI should warn that omitted fields will be reset.
🤖 Generated with Claude Code