-
Notifications
You must be signed in to change notification settings - Fork 23
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
Use TransactionInfo
within GetTransactionResponse
#251
Conversation
TransactionInfo
within GetTransactionResponse
TransactionInfo
within GetTransactionResponse
TransactionInfo
within GetTransactionResponse
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.
Much cleaner !! just one comment on removing the status
field
@@ -29,8 +29,6 @@ const ( | |||
|
|||
// GetTransactionResponse is the response for the Soroban-RPC getTransaction() endpoint | |||
type GetTransactionResponse struct { | |||
// Status is one of: TransactionSuccess, TransactionNotFound, or TransactionFailed. | |||
Status string `json:"status"` |
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 could still keep the Status
field to show what actually happened with Txn. Any strong motive to remove this field? or is it rarely used by users?
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.
Well it's still part of TransactionInfo
. It can take on one additional value (TransactionNotFound
) for this endpoint, but since it's a string
regardless this doesn't impact the code.
WARNING: This is a breaking API change; see Known limitations, below.
What
Use
TransactionInfo
(from thegetTransactions()
handler) as part of thegetTransaction()
handler.Why
One is a subset of the other, and this makes it easier for both the code and documentation to reflect that.
It also guarantees that the endpoints don't diverge in the future.
This is partially related to #124, where I realized I was duplicating work by parsing out the transaction fields separately for each endpoint: this would make the work more streamlined.
Known limitations
According to the CI integration test runs, this breaks
getTransaction
's integration tests becausecreatedAt
is encoded as anint64
rather than astring
in the schema forgetTransactions
. We need to change this for JavaScript which is a breaking API change.