You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While some APIs (at least transactions/pending, applications/{application-id}/boxes, and account/{address}) can return extra information in the .Data field of the REST request. Today, goal only prints the message, not the extra data.
Expected
There should be a way to get this information. Possibly in human readable form (especially for the box and account endpoints, for which the information is small and bounded), and possibly in a program consumable form (perhaps spit out the JSON).
I think we ought to maintain the stance that this information is not (yet) guaranteed to maintain that form. We don't really even have a semvar regime for goal.
Solution
Maybe this just means a -v (verbose) flag for boxes and accounts that prints the 2 or 3 fields as human readable message.
For the pending endpoint, maybe -v is also the answer, but it prints JSON (so we don't have to come up with human sentences for the verbose output). Or maybe it's a different flag, since JSON feels different?
Urgency
My opinion is that the pending endpoint change is much more valuable, so it has some priority. The other endpoints are quite "static" in their use of Data, they report limits that the user is running up against.
The text was updated successfully, but these errors were encountered:
If somehow a "verbose" option is enabled, print the message string and any structured data that's present. Right now goal routes almost all error printing through reportErrorf so we'd probably want to change this or introduce a new variant, since it takes a string arg, not an error, so it would be a bit tedious.
Status
While some APIs (at least
transactions/pending
,applications/{application-id}/boxes
, andaccount/{address}
) can return extra information in the.Data
field of the REST request. Today,goal
only prints the message, not the extra data.Expected
There should be a way to get this information. Possibly in human readable form (especially for the box and account endpoints, for which the information is small and bounded), and possibly in a program consumable form (perhaps spit out the JSON).
I think we ought to maintain the stance that this information is not (yet) guaranteed to maintain that form. We don't really even have a semvar regime for
goal
.Solution
Maybe this just means a
-v
(verbose) flag for boxes and accounts that prints the 2 or 3 fields as human readable message.For the
pending endpoint
, maybe-v
is also the answer, but it prints JSON (so we don't have to come up with human sentences for the verbose output). Or maybe it's a different flag, since JSON feels different?Urgency
My opinion is that the
pending
endpoint change is much more valuable, so it has some priority. The other endpoints are quite "static" in their use ofData
, they report limits that the user is running up against.The text was updated successfully, but these errors were encountered: