feat(cli): add inference set-owner - #139
Merged
Merged
Conversation
`set-beneficiary` had no counterpart for the owner address, so an operator whose owner address was never set had no CLI path to write one. The platform accepts an owner address only while it is empty and refuses any later change. Two consequences shape the command: - It reads the current value first. If an owner is already stored, it explains that and stops rather than sending a call that will be refused; if the stored value already equals the argument, it says so and exits cleanly. - It confirms before writing, since the write cannot be undone. `--yes` skips the prompt for scripts. set-beneficiary needs no confirmation because running it again corrects a mistake. Address validation moves into a shared validateEthAddress and now rejects non-hex characters, which the previous prefix-and-length check accepted — a transposed character landing on a letter would otherwise have been written to a field that cannot be corrected. On success it reads the stored value back rather than echoing the argument, as set-beneficiary does.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes the second half of #134. Part 1 (showing both addresses in
inference status) shipped in #135.Why this is not blocked after all
#134 recorded
set-owneras blocked, on the grounds that the platform refuses aprovider-initiated owner-address change. That is true of a change, but the
rule only rejects a write when an owner address is already stored — an empty one
is accepted. Providers whose owner address was never set therefore have a
working path today, and this node is one of them (
inference statusreportsOwner: not set).So the command is useful now, and correct later: if the platform ever allows a
change, only the already-set branch needs revisiting.
Shape
Matches
set-beneficiary— same endpoint, same key, same read-back on success —with two differences that come from the write being one-way:
explains that and stops instead of sending a call the platform will refuse;
if the stored value already equals the argument, it says so and exits 0.
--yesskips the prompt for scripts.
set-beneficiaryhas no such prompt and shouldnot — running it again corrects a mistake, and this cannot.
Validation
Address checking moves into a shared
validateEthAddress, used by bothcommands, and now rejects non-hex characters. The previous prefix-and-length
check accepted
0x…93z: a transposed character landing on a letter would havepassed validation and been written to a field with no correction path.
Verified against the live platform
Owner: not set, and promptsI did not complete a real write: setting an owner address on the production node
is irreversible and is not mine to choose. The already-set branch is likewise
unexercised for the same reason — it is covered by reading the stored value, not
by provoking a server-side refusal.