schemas update: confirm step (--digest/--confirm) returns ok:true but never persists the change

[rverheijen]

Version: hubspot 0.14.0 (build 1162, commit unknown)

Command run:

$ PATCH='{"labels":{"singular":"ZZ Push Test","plural":"ZZ Push Tests MANUAL"}}'
$ DIGEST=$(echo "$PATCH" | hubspot schemas update --type 2-253815111 --dry-run | jq -r '.digest')
$ echo "$PATCH" | hubspot schemas update --type 2-253815111 --digest "$DIGEST" --confirm 'zz_push_test'

Expected result: the schema's labels.plural is updated to "ZZ Push Tests MANUAL", matching what the confirm call's own response claims to have applied.

Actual result: the confirm call returns ok: true with a data payload that shows the new value, but the change is never written. Re-fetching immediately after (and repeatedly for 25s afterward) shows the old value unchanged:

$ echo "$PATCH" | hubspot schemas update --type 2-253815111 --digest "$DIGEST" --confirm 'zz_push_test'
{"name":"2-253815111","ok":true,"data":{"labels":{"singular":"ZZ Push Test","plural":"ZZ Push Tests MANUAL"},...}}

$ hubspot schemas get --type 2-253815111 --format json | jq '.data[0].labels'
{"singular":"ZZ Push Test","plural":"ZZ Push Tests"}

Reproduced twice independently (once via a wrapper script, once with the raw commands above in isolation, no other operations in between).

Why this matters: the README's own beta warning recommends using --dry-run before mutations as the safety practice for a tool that can modify live CRM data. This defeats that practice for schemas update specifically - the confirm step that --dry-run leads into silently no-ops while reporting success.

Also noticed while investigating: the dry-run response's apply_command_hint field (e.g. hubspot schemas update 2-253815111 --digest blast-... --confirm 'zz_push_test') omits --file/stdin, which is misleading on its own - the confirm call does require the same JSON body piped again, or it fails with "No schema body provided".

[bkawa-io]

Thanks @rverheijen ! We will take a look along with #8