-
Notifications
You must be signed in to change notification settings - Fork 5
Ajw/164 tx blockfrost api #370
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
base: main
Are you sure you want to change the base?
Conversation
- returns a tiny bit of transaction info given a tx hash
whankinsiv
left a 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.
Looks great! Just a few fields whose names don't align with the BF schema.
common/src/queries/transactions.rs
Outdated
| #[derive(Debug, Clone, serde::Deserialize)] | ||
| pub enum TransactionOutputAmount { | ||
| Lovelace(Lovelace), | ||
| Asset(NativeAsset), | ||
| } | ||
|
|
||
| impl Serialize for TransactionOutputAmount { |
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.
If a type implements both Serialize and Deserialize, they should match; otherwise the data can't round-trip. Would be better to either
- have a different struct specifically in
rest_blockfrostwhich deserializes correctly - make
TransactionOutputAmountinto a struct withunitandamountfields, so (de)serialization works right - not implement
Deserializehere (and we make caryatid not depend on it [obvs lots of extra work there])
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'm going for a 4th option, which is to apply the standard Serialize derive in common, and move the special serialization into rest_blockfrost. This is one of the cases where the serialization for blockfrost is kind of unusual due to the numerics being serialized to strings. It makes some sense for JSON, but for CBOR it's not good. I think we would benefit from picking a default serialization target for common structs, and I think it should probably be CBOR. Shout if you think this is the wrong approach
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 should probably refactor these to return Result<N> at some point 😓
@whankinsiv Do you have a tool for checking these? |
Description
This PR adds some of the txs endpoints to the REST Blockfrost module.
Related Issue(s)
Relates to #137, #164.
How was this tested?
Manual comparison against dbsync (mainnet) :-(
Example requests that should work on mainnet:
Checklist
Impact / Side effects
There shouldn't be any side-effects.
Reviewer notes / Areas to focus
I've made custom serialisers within the blockfrost code. I'm unsure if there's a nicer way to do what I was trying to do, which was to keep serialisation out of the common library because in many cases this serialisation is quite peculiar to blockfrost and should not be a default.