rpc: add expiry field to getgeneralinfo#247
rpc: add expiry field to getgeneralinfo#247Retropex wants to merge 1 commit intobitcoinknots:29.x-knotsfrom
Conversation
|
Knots exposing expiry via RPC is the correct layer. |
|
Not sure having its own RPC makes sense. Maybe one of the existing get*info is a good place? |
|
Make sense, I will update |
Retropex
force-pushed
the
rpcexpiry
branch
2 times, most recently
from
5b1eef4 to
86b4d02
Compare
| {RPCResult::Type::STR, "datadir", "Data directory path"}, | ||
| {RPCResult::Type::STR, "blocksdir", "Blocks directory path"}, | ||
| {RPCResult::Type::NUM, "startuptime", "Startup time"}, | ||
| {RPCResult::Type::NUM_TIME, "expiry", "Expiry timestamp"}, |
There was a problem hiding this comment.
This will type-mismatch if boolean
src/rpc/node.cpp
Outdated
| [&](const RPCHelpMan& self, const JSONRPCRequest& request) -> UniValue | ||
| { | ||
| const ArgsManager& args{EnsureAnyArgsman(request.context)}; | ||
| int64_t expiry = g_software_expiry <= 0 ? false : g_software_expiry; |
There was a problem hiding this comment.
This will turn the false into a 0.
There was a problem hiding this comment.
I don't get it, isn't false == 0?
There was a problem hiding this comment.
Not in JSON. Booleans and Numbers are distinct types.
There was a problem hiding this comment.
I don't think returning two different type for the same entry is a good idea.
We should keep zero as a special value to signal that it's disabled, as it's done in bitcoin.conf
Retropex
changed the title
4 participants
Useful for external software who want to be able to fetch when
bitcoindwill expire.