-
Notifications
You must be signed in to change notification settings - Fork 15
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
transaction submit: print transaction hash #925
base: master
Are you sure you want to change the base?
Conversation
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 shouldn't add more print statements here. A more principled approach would be to query the mempool to confirm that tx has been submitted and we can derive the txid from the tx itself. Why are we printing the txid here in the first place?
This PR is an answer to this ask by a user: #896. Design has been validated by @CarlosLopezDeLara. |
Responded. We need to know what they intend to do with the information and that will inform what changes we should make, if any. |
I believe this feature adds good value. After submitting a transaction, it's common to share the transaction ID (txid) with the recipient or check it in a blockchain explorer. Including the txid in the output seems like a natural addition, as it's the key information needed for any follow-up. Of course, one can compute the tx-id with |
7799011
to
feffd34
Compare
feffd34
to
1ee583f
Compare
newtype TxIdSubmission = TxIdSubmission {txhash :: T.Text} | ||
deriving (Show, Generic) | ||
|
||
instance FromJSON TxIdSubmission |
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've put the FromJSON
instance too, in case independent Haskell tooling wants to use it.
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.
What's wrong with FromJSON TxId
?
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.
@Jimbo4350: see #925 (comment)
liftIO $ Text.putStrLn "Transaction successfully submitted. Transaction hash is:" | ||
let hashText = T.decodeUtf8 $ serialiseToRawBytesHex (getTxId $ getTxBody tx) | ||
liftIO $ LBS.putStrLn $ Aeson.encode $ TxIdSubmission hashText |
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.
The message should go to stderr, the hash should go to stdout. Otherwise it'll be a hassle to separate one from the other.
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 not sure: do we do that already? It could surprise the user if we separate the two (because they are really both not errors!).
I wrote the JSON on a separate line so that ... | tail -n 1
works for retrieving it.
cc @CarlosLopezDeLara, in case you have insights on our conventions for printing so far.
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 we should start doing it. tail -n 1
is wonky, because it assumes hidden knowledge about the output format, which can change between commands and over time.
That's pretty much way of outputting things in various unix tools.
stdout
for output datastderr
for diagnostic messages
Try find /proc 1>/dev/null
and find /proc 2>/dev/null
.
If we're not doing it alredy I believe this is a good place for a precedent.
@Jimbo4350 thoughts?
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.
Agreed during yesterday's team meeting to do it, so it's implemented now 👍
1ee583f
to
9fbd897
Compare
|
||
-- | Type used for serialization when printing the hash of a transaction | ||
-- after having submitted it. | ||
newtype TxIdSubmission = TxIdSubmission {txhash :: TxId} |
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 still don't like this type name 😄
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.
The newtype
is unnecessary. It's obvious that this is the txid of the submitted transaction and we are using the underlying TxId
JSON instances. What is the benefit of this newtype
definition?
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 we were using this value in multiple places and could mix it up with other TxId
s, I would agree with the newtype
definition. However, it's used in one place, so it's overkill.
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.
This newtype is so that we output this JSON on stdout:
{"txhash": "d9290bc8f8f412660109e3c9740d89c19f2ba6697508fd9d4b4b54f32a2ba02e"}
If we were to use TxID
's JSON format directly, we would have:
"d9290bc8f8f412660109e3c9740d89c19f2ba6697508fd9d4b4b54f32a2ba02e"
which we ruled out during our team meeting a few weeks ago (because "it wasn't JSON"). So in the end, I'm not sure what you guys want!?
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.
My gripe is with the type name. I understand it currently as "a submission of transaction id" which is unclear in my opinion. A better name would be "a result of a transaction submission", for example: TxSubmissionResult
.
This is non-critical though. I'm leaving an approval to @Jimbo4350 since he blocked the PR originally.
By the way,
"d9290bc8f8f412660109e3c9740d89c19f2ba6697508fd9d4b4b54f32a2ba02e"
is a valid JSON so I don't get the argument. 😄
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.
Decided during today's team meeting: let's go for the {"txhash": "d9290bc8f8f412660109e3c9740d89c19f2ba6697508fd9d4b4b54f32a2ba02e"}
and separate JSON from English by using stdout
and stderr
, as @carbolymer suggested here.
9fbd897
to
2e301c2
Compare
Changelog
Context
Fixes #896
How to trust this PR
We added a test in
cardano-testnet
: IntersectMBO/cardano-node#6003Checklist