Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

goal should make extra information provided in some API requests available #5908

Open
jannotti opened this issue Jan 18, 2024 · 1 comment
Open

Comments

@jannotti
Copy link
Contributor

jannotti commented Jan 18, 2024

Status

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.

@jannotti
Copy link
Contributor Author

jannotti commented Jan 18, 2024

Note from @jasonpaulos

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant