-
Notifications
You must be signed in to change notification settings - Fork 37.7k
net, rpc: expose nLastBlockTime/nLastTXTime as last block/last_transaction in getpeerinfo #19731
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
net, rpc: expose nLastBlockTime/nLastTXTime as last block/last_transaction in getpeerinfo #19731
Conversation
ACK on the C++ code change I'll leave it up to @MarcoFalke to review the test, it might be a time dependency like this without using mocking makes the test too brittle / time dependent. |
5c1ec86
to
7da71af
Compare
Agree, I'm not sure here either. Edit: loosened the tests to not be time-dependent. |
7da71af
to
062614f
Compare
src/rpc/net.cpp
Outdated
{RPCResult::Type::NUM_TIME, "last_transaction", "The " + UNIX_EPOCH_TIME + " of the last transaction accepted and relayed by this peer"}, | ||
{RPCResult::Type::NUM_TIME, "last_block", "The " + UNIX_EPOCH_TIME + " of the last block accepted and relayed by this peer "}, |
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 don't think 'accepted and relayed by' is quite right:
For last_transaction
, it's the time of the last transaction that we received and accepted into our mempool. I think the time of the last valid transaction received from this peer
is accurate.
For last_block
, it's the time of the last block that we received and saved to disk (even if we don't connect the block or it eventually fails connection). I think the time of the last block received from this peer
is fine here.
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.
Thanks @jnewbery! I was just reconsidering those as well. Updating.
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.
Unresolving to make the head comment visible for reviewers and future code doc writers.
062614f
to
5da9621
Compare
Updated with @jnewbery feedback (thanks!) |
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.
Concept ACK.
------------ | ||
|
||
- The `getpeerinfo` RPC now has additional `last_block` and `last_transaction` | ||
fields that return the UNIX epoch time of the last block and the last valid |
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.
nit, last valid block too.
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.
No. nLastBlockTime
is updated even if connecting the block fails.
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.
Thanks @jnewbery. I found figuring out their exact definition to be the most interesting part of this PR. More precise code documentation than
net.h
Block and TXN accept timesnet.cpp::AttemptToEvictConnection
recently sent us transactions/recently sent us blocks
might be worth adding/updating.
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.
More code documentation ... might be worth adding/updating.
Certainly! Although it doesn't have to be in this PR.
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.
More code documentation ... might be worth adding/updating.
Certainly! Although it doesn't have to be in this PR.
Agreed!
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.
Right, got confused by fNewBlock.
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.
Improved the documentation in #19857.
@@ -169,6 +171,8 @@ static UniValue getpeerinfo(const JSONRPCRequest& request) | |||
obj.pushKV("relaytxes", stats.fRelayTxes); | |||
obj.pushKV("lastsend", stats.nLastSend); | |||
obj.pushKV("lastrecv", stats.nLastRecv); | |||
obj.pushKV("last_transaction", stats.nLastTXTime); |
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.
nit, I don't have an alternative but last_transaction
suggests it returns the actual transaction, not a timestamp.
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.
nit, I don't have an alternative but
last_transaction
suggests it returns the actual transaction, not a timestamp.
I considered adding _time
to the names, but we already have timestamp fields both with and without "time" (conntime
, lastsend
, lastrecv
), so I went for the shorter variants unless everyone prefers last_transaction_time
and last_block_time
instead.
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 fine with either, although I think last_block_time
could still be confusing, since one interpretation could be the timestamp in the block.
Code review ACK 5da9621 |
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ConflictsReviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. |
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.
Code Review ACK 5da9621
Just out of curiosity, any reason why you changed the execution order of the tests?
Good question. It mattered for an earlier version of the test and no longer matters now, and I forgot to revert to the previous order. I don't think there was anything critical or sacred about the previous order, but I don't mind reverting that if someone thinks it's better to do so. |
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.
ACK 5da9621
…ast block/last_transaction in getpeerinfo 5da9621 doc: release note for getpeerinfo last_block/last_transaction (Jon Atack) cfef5a2 test: rpc_net.py logging and test naming improvements (Jon Atack) 21c57ba test: getpeerinfo last_block and last_transaction tests (Jon Atack) 8a560a7 rpc: expose nLastBlockTime/TXTime as getpeerinfo last_block/transaction (Jon Atack) 02fbe3a net: add nLastBlockTime/TXTime to CNodeStats, CNode::copyStats (Jon Atack) Pull request description: This PR adds inbound peer eviction criteria `nLastBlockTime` and `nLastTXTime` to `CNodeStats` and `CNode::copyStats`, which then allows exposing them in the next commit as `last_transaction` and `last_block` Unix Epoch Time fields in RPC `getpeerinfo`. This may be useful for writing missing eviction tests. I'd also like to add `lasttx` and `lastblk` columns to the `-netinfo` dashboard as described in bitcoin#19643 (comment). Relevant discussion at the p2p irc meeting http://www.erisian.com.au/bitcoin-core-dev/log-2020-08-11.html#l-549: ```text <jonatack> i was specifically trying to observe and figure out how to test bitcoin#19500 <jonatack> which made me realise that i didn't know what was going on with my peer conns in enough detail <jonatack> i'm running bitcoin locally with nLastBlockTime and nLastTXTime added to getpeerinfo for my peer connections dashboard <jonatack> sipa: is there a good reason why that (eviction criteria) data is not exposed through getpeerinfo currently? <sipa> jonatack: nope; i suspect just nobody ever added it <jonatack> sipa: thanks. will propose. ``` The last commit is optional, but I think it would be good to have logging in `rpc_net.py`. ACKs for top commit: jnewbery: Code review ACK 5da9621 theStack: Code Review ACK 5da9621 darosior: ACK 5da9621 Tree-SHA512: 2db164bc979c014837a676e890869a128beb7cf40114853239e7280f57e768bcb43bff6c1ea76a61556212135281863b5290b50ff9d24fce16c5b89b55d4cd70
d780293 net: improve nLastBlockTime and nLastTXTime documentation (Jon Atack) Pull request description: Follow-up to #19731 to help alleviate confusion around `nLastBlockTime` and `nLastTXTime`, now also provided by the JSON-RPC API as `last_block` and `last_transaction` in `getpeerinfo` output. Thanks to John Newbery, credited in the commit, and to Dave Harding and Adam Jonas during discussions on how to best explain these in this week's Optech newsletter. ACKs for top commit: practicalswift: ACK d780293 MarcoFalke: ACK d780293 harding: ACK d780293 . The added documentation matches my reading of the code and answers a question I had after seeing #19731 0xB10C: ACK d780293 Tree-SHA512: 72d47cf50a099913c7e4753cb80e11785b26fb66fa3a8b6c382fde4ea725116f3d215f93d32a567246d269768e66159f8dcf017a1bbc6d5f2489a35f81c316fa
…ction in getpeerinfo Summary: ``` This PR adds inbound peer eviction criteria nLastBlockTime and nLastTXTime to CNodeStats and CNode::copyStats, which then allows exposing them in the next commit as last_transaction and last_block Unix Epoch Time fields in RPC getpeerinfo. ``` Backport of [[bitcoin/bitcoin#19731 | core#19731]]. Depends on D9324 and D9330. Test Plan: ninja all check-all Reviewers: #bitcoin_abc, PiRK Reviewed By: #bitcoin_abc, PiRK Differential Revision: https://reviews.bitcoinabc.org/D9331
…mentation d780293 net: improve nLastBlockTime and nLastTXTime documentation (Jon Atack) Pull request description: Follow-up to bitcoin#19731 to help alleviate confusion around `nLastBlockTime` and `nLastTXTime`, now also provided by the JSON-RPC API as `last_block` and `last_transaction` in `getpeerinfo` output. Thanks to John Newbery, credited in the commit, and to Dave Harding and Adam Jonas during discussions on how to best explain these in this week's Optech newsletter. ACKs for top commit: practicalswift: ACK d780293 MarcoFalke: ACK d780293 harding: ACK d780293 . The added documentation matches my reading of the code and answers a question I had after seeing bitcoin#19731 0xB10C: ACK d780293 Tree-SHA512: 72d47cf50a099913c7e4753cb80e11785b26fb66fa3a8b6c382fde4ea725116f3d215f93d32a567246d269768e66159f8dcf017a1bbc6d5f2489a35f81c316fa
…mentation d780293 net: improve nLastBlockTime and nLastTXTime documentation (Jon Atack) Pull request description: Follow-up to bitcoin#19731 to help alleviate confusion around `nLastBlockTime` and `nLastTXTime`, now also provided by the JSON-RPC API as `last_block` and `last_transaction` in `getpeerinfo` output. Thanks to John Newbery, credited in the commit, and to Dave Harding and Adam Jonas during discussions on how to best explain these in this week's Optech newsletter. ACKs for top commit: practicalswift: ACK d780293 MarcoFalke: ACK d780293 harding: ACK d780293 . The added documentation matches my reading of the code and answers a question I had after seeing bitcoin#19731 0xB10C: ACK d780293 Tree-SHA512: 72d47cf50a099913c7e4753cb80e11785b26fb66fa3a8b6c382fde4ea725116f3d215f93d32a567246d269768e66159f8dcf017a1bbc6d5f2489a35f81c316fa
…mentation d780293 net: improve nLastBlockTime and nLastTXTime documentation (Jon Atack) Pull request description: Follow-up to bitcoin#19731 to help alleviate confusion around `nLastBlockTime` and `nLastTXTime`, now also provided by the JSON-RPC API as `last_block` and `last_transaction` in `getpeerinfo` output. Thanks to John Newbery, credited in the commit, and to Dave Harding and Adam Jonas during discussions on how to best explain these in this week's Optech newsletter. ACKs for top commit: practicalswift: ACK d780293 MarcoFalke: ACK d780293 harding: ACK d780293 . The added documentation matches my reading of the code and answers a question I had after seeing bitcoin#19731 0xB10C: ACK d780293 Tree-SHA512: 72d47cf50a099913c7e4753cb80e11785b26fb66fa3a8b6c382fde4ea725116f3d215f93d32a567246d269768e66159f8dcf017a1bbc6d5f2489a35f81c316fa
This PR adds inbound peer eviction criteria
nLastBlockTime
andnLastTXTime
toCNodeStats
andCNode::copyStats
, which then allows exposing them in the next commit aslast_transaction
andlast_block
Unix Epoch Time fields in RPCgetpeerinfo
.This may be useful for writing missing eviction tests. I'd also like to add
lasttx
andlastblk
columns to the-netinfo
dashboard as described in #19643 (comment).Relevant discussion at the p2p irc meeting http://www.erisian.com.au/bitcoin-core-dev/log-2020-08-11.html#l-549:
The last commit is optional, but I think it would be good to have logging in
rpc_net.py
.