-
Notifications
You must be signed in to change notification settings - Fork 207
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
feat(cosmos): Add a "CapData" vstorage RPC endpoint #8056
Conversation
chore(cosmos): Fix Go formatting
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know Go well enough to review the implementation. The thrust of the design makes sense to me. I'd like to see some tests that demonstrate the interface for clients. (e.g. example responses)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
examples / tests are critical, I think
|
539e2a3
to
d8522cc
Compare
d8522cc
to
36b921d
Compare
var capDataRemotableValueFormats = map[string]string{ | ||
FormatRemotableAsObject: FormatRemotableAsObject, | ||
FormatRemotableAsString: FormatRemotableAsString, | ||
// No default. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
with no default, is it an error when the request omits this parameter? object
seems to me the appropriate default as it's the most generic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I decided that omitting FormatRemotableAsString should be an error because all valid values are lossy w.r.t. CapData.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah I see. that rationale would be worth including in the comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
// * "object" represents each Remotable as an `{ id, allegedName }` object. | ||
// * "string" represents each Remotable as a bracketed string such as `[Alleged: IST brand {}]`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is important documentation. is it published somewhere using godoc ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not that I know of (as mentioned in the PR summary, we don't seem to have any documentation of RPC endpoints). Does anyone have a place where they would expect to find it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we don't seem to have any documentation of RPC endpoints
It's far from perfect, but we have >0 for inter protocol RPC stuff: https://github.com/Agoric/agoric-sdk/tree/master/packages/inter-protocol#reading-data-off-chain
As to the rest, yes, it's been a hole in our docs for some time; I put what notes I learn in...
In some sense, this is a different issue, since that issue was about documentation of the form "Agoric stuff is based on cosmos-sdk; go read XYZ to find out how the lower level works." It turns out that there's no obvious candidate for XYZ, btw.
Does anyone have a place where they would expect to find it?
The inter-protocol precedent suggests a readme under golang/cosmos/x/vstorage
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added golang/cosmos/x/vstorage/README.md.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, it turns out that the documentation is available via godoc of the generated pb.go.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see how clients can work if Id
is left out of remotable string rendering.
// capdataRemotableToString represents a Remotable as a bracketed string | ||
// containing its alleged name (e.g., "[Foo {}]"). | ||
func capdataRemotableToString(r *capdata.CapdataRemotable) interface{} { | ||
iface := "Remotable" | ||
if r.Iface != nil || *r.Iface != "" { | ||
iface = *r.Iface | ||
} | ||
return fmt.Sprintf("[%s {}]", iface) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In order to prevent clients from relying on the Iface
(aka debug name) for correctness, the rendering of a remotable must preserve the Id. Including the Iface
at all is risky.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Per #7581, this attempts to align with agoric follow -o jsonlines
:
agoric --sdk follow :published.vaultFactory.manager0.metrics -B https://devnet.agoric.net/network-config --proof none -o jsonlines | jq . { "liquidatingCollateral": { "brand": "[Alleged: SEVERED: IbcATOM brand {}]", "value": "0" }, …
Who constitutes the right group to discuss well-motivated deviation? @arirubinstein?
if r.Iface != nil || *r.Iface != "" { | ||
iface = *r.Iface | ||
iface, _ = strings.CutPrefix(iface, "Alleged: ") | ||
iface, _ = strings.CutSuffix(iface, " brand") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why cut off "brand"? Why should this code have knowledge of ERTP?
cc @erights
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This attempts to align with scripts/get-flattened-publication.sh. I'm open to deviation here as well, but again unclear about authority for making such a decision.
b39ca47
to
a7f17fe
Compare
This PR now features what AFAICT is the most comprehensive Go testing in the repository, for both the capdata decoder and the CapData gRPC endpoint. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Title says "CapData". Did you mean "smallcaps"?
…Data remotable representations
Nope, it's formatting CapData regardless of smallcaps vs. legacy encoding. |
We decided at the cosmic-swingset meeting that reducing lossiness is more important than preserving precise compatibility with
@turadg, please confirm that this works for you. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
WFM. Glad to see the eventual design had support in the full cosmic-swingset group.
feat(cosmos): Add a "CapData" vstorage RPC endpoint
feat(cosmos): Add a "CapData" vstorage RPC endpoint
Fixes #7581
Description
RPC requests with path "/agoric.vstorage.Query/CapData" will get back vstorage data that has been interpreted as CapData and (lossily) formatted in the style of
agoric follow
orscripts/get-flattened-publication.sh
.Security Considerations
There is no expected change in security posture. Clients can continue to request the raw data; this interface just provides a convenient way for them to keep up with potential future changes in CapData representation without having to run local transformations.
Scaling Considerations
Use of the new endpoint represents more work for an RPC node and generation of some more Go garbage, but the impact should be negligible (and the responses theirselves will be smaller).
Documentation Considerations
We don't seem to have any documentation of RPC endpoints. Perhaps @Tyrosine22 has thoughts on how to address that?
Testing Considerations
I'm still considering options for how to test the CapData decoder at golang/cosmos/x/vstorage/capdata/capdata.go , and will probably add some static tests mirroring those in https://github.com/endojs/endo/tree/master/packages/marshal but would also like to roll something more into endojs/endo#1588 where endo publishes a generic conformance testing artifact that is imported and used in the testing of this Go package.