-
Notifications
You must be signed in to change notification settings - Fork 280
feat(pyth-lazer) Create schema for lazer agent JRPC endpoint #2836
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
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 8 Skipped Deployments
|
lazer/sdk/rust/protocol/src/jrpc.rs
Outdated
} | ||
|
||
#[derive(Serialize, Deserialize)] | ||
struct SymbolMetadata { |
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.
let's aim for a map <str -> str> for metadata. i think anything that is usable in the code should not live in metadata (like exponent) but that's a step in the future.
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 think BTreeMap<String, serde_value::Value>
would be even better. We should support typed metadata instead of converting everything to string. I also agree about separating exponent, etc from arbitrary metadata.
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.
separating exponent, etc
Which fields do you consider to not be a part of the arbitrary metadata?
…eat/pyth-lazer/agent/jrpc-schema-1
da25fcd
to
28e1346
Compare
Summary
Add a new schema for the JRPC endpoint in
pyth-lazer-agent
for sending updates, and retrieving metadata via the JRPC endpoint. Also move theTimestamp
logic toprotocol
to reuse acrosspyth-lazer
Rationale
Adding a new endpoint for publishers to communicate with the
pyth-lazer-agent
.How has this been tested?