-
Notifications
You must be signed in to change notification settings - Fork 52
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
Blockfrost metadata and confirmation #1368
Blockfrost metadata and confirmation #1368
Conversation
5961421
to
b8634b5
Compare
…behaviour of metadata fetching in kupo and blockfrost.
…tadata-and-confirmation
case unwrapKupoMetadata kupoMetadata of | ||
Nothing -> throwError GetTxMetadataMetadataEmptyOrMissingError | ||
Just metadata | ||
| Map.isEmpty (unwrap metadata) -> throwError |
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 we need to handle empty Map case?
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.
To make the API the same for blockfrost and kupo.
Blockfrost gives us the same information in the empty metadata case, regardless of whether it actually had the optional metadata field attached. Kupo on the other hand returns exactly what the transaction contained,
The alternative could be to always make the kupo version return an empty metadata on the case where there was none, but I think if users are requesting metadata from a transaction, they probably expect some 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.
Not sure if I explained that well, maybe this makes it clearer:
No metadata:
blockfrost: []
kupo: []
Empty metadata:
blockfrost: []
kupo: [ ... ]
With metadata:
blockfrost: [ ... ]
kupo: [ ... ]
…tadata-and-confirmation
@@ -88,14 +88,14 @@ runBlockfrostServiceM backend = flip runReaderT serviceParams | |||
-------------------------------------------------------------------------------- | |||
|
|||
data BlockfrostEndpoint | |||
= GetTransaction TransactionHash | |||
| GetTransactionMetadata TransactionHash | |||
= Transaction TransactionHash |
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 change from Get
?
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 theory an endpoint can support multiple HTTP methods, GET/POST/PUT/DELETE etc. It also looked a little redundant seeing blockfrostGetRequest $ Get...
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 good
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 good to me
Part of #1365
Pre-review checklist
make format
)## Unreleased
header, using the appropriate sub-headings (### Added
,### Removed
,### Fixed
), and the links to the appropriate issues/PRs have been included