feat(cli): show the wallet addresses in inference status - #135
Merged
Conversation
Neither the owner nor the beneficiary address was visible from the CLI, so an operator on a headless box could not see what either was set to without opening the dashboard. Both are already returned by GET /api/v1/provider/me, behind the same provider API key set-beneficiary uses, so this needs nothing from the platform. set-beneficiary now reads the stored value back instead of echoing the argument. Repeating what was typed confirms nothing; the point is to see what the platform holds. It also warns when the two differ. Addresses print in full rather than abbreviated. The reason to read one back is to confirm it is the address you meant, and a truncated form hides the middle, which is exactly where a transposed character would sit. Two things kept deliberate: The address lookup is a second endpoint, and it is advisory. A status report must not fail because one extra call did, so a failure omits the addresses and prints everything else. In --json the addresses are embedded, not nested. Every key that was there before stays exactly where it was, so anything already parsing that output keeps working and the addresses are simply additional fields. Covers part 1 of the request only. set-owner is left alone: the platform refuses a provider-initiated owner change today, so the command could only ever fail.
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
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.
Part 1 of #134. Part 2 (
set-owner) is deliberately untouched — the platform refuses a provider-initiated owner change today, so the command could only ever fail.What changed
inference statusnow prints the addresses the platform holds:set-beneficiaryreads the stored value back instead of echoing the argument. Repeating what was typed confirms nothing — the point of showing it is to see what the platform now holds, on the same terminal. It also warns if the two differ.No platform change needed: both come from
GET /api/v1/provider/me, behind the same provider API keyset-beneficiaryalready uses.Three decisions worth reviewing
Addresses print in full, not abbreviated. The issue's sketch showed
0x46f2…F93c, but the stated purpose is confirming the value landed on the address you meant — and a truncated form hides the middle, which is exactly where a transposed character sits. Happy to switch to the abbreviated form if the intent was display-only.The lookup is advisory. It is a second endpoint, so a failure omits the addresses and prints the rest of the status. A diagnostic command should not fail because one extra call did.
--jsonkeeps its existing shape. The addresses are embedded, not nested — every key that was there before stays where it was:My first attempt nested the status under a
statuskey, which would have broken anything already parsing it. There is a test pinning the flat shape so it cannot regress.Verified
Run against the live API on a provider whose addresses are all empty, which is the case most likely to render badly — both the human output and
--jsonare correct, andnot setreads clearly.3 tests: the fetch (path and auth header asserted), a non-200 surfacing as an error rather than an empty address set, and the flat JSON contract.
8/8 packages,
go vetandgofmtclean. Documented indocs/cli/README.md.