Ajw/164 tx blockfrost api #370
Conversation
- returns a tiny bit of transaction info given a tx hash
alexwoods
requested review from
SupernaviX,
sandtreader and
whankinsiv
and removed request for
whankinsiv
whankinsiv
left a comment
whankinsiv
left a comment
There was a problem hiding this comment.
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.
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.
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.
I should probably refactor these to return Result<N> at some point 😓
@whankinsiv Do you have a tool for checking these? |
sandtreader
left a comment
sandtreader
left a comment
There was a problem hiding this comment.
Massive piece of work, good job!
Only queries are about possible missing Conway certs where you can register and delegate at the same time, and whether counting PoolRegistrations is enough for deposits.
| // TODO: calc from outputs and inputs if recorded_fee is None | ||
| let fee = txs_info.recorded_fee.unwrap_or_default(); | ||
| let deposit = match calculate_deposit( | ||
| txs_info.pool_update_count, |
There was a problem hiding this comment.
Worried about this - check if deposit is paid for subsequent updates of the same pool reg.
There was a problem hiding this comment.
(I have no idea what to do if it isn't, since it requires SPO state)
There was a problem hiding this comment.
I will add a comment to check for now
| Err(e) => return Some(Err(e)), | ||
| }; | ||
| // TODO: calc from outputs and inputs if recorded_fee is None | ||
| let fee = txs_info.recorded_fee.unwrap_or_default(); |
There was a problem hiding this comment.
There is code to do this in common/transactions I think?
There was a problem hiding this comment.
I can't find it. The problem is that for early eras there is no fee amount recorded in the tx and it's calculated from the tx in values. Unfortunately, when I was writing this there was no way to get those since utxo store history was keyed by UTxOIdentifier. Hopefully the reverted keying type will make this possible.
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.