Different RPC behavior between cuprated and monerod

[hinto-janai]

What

This is a discussion for daemon RPC calls in cuprated that will behave differently than monerod or not be supported.

The RPC calls considered are the publically available ones from cc73fe7.

In general, adhoc string fields in monerod (including errors) will most likely differ in cuprated.

Different behavior

This table describes RPC calls that will exist in cuprated but will have slightly different behavior than monerod.

RPC method/endpoint	Reason
get_connections	TODO: peer_id, connection_id: #278 (comment)
get_info	TODO: update_available, version fields
version	TODO
/set_log_level	cuprated's log levels may differ from monerod's
/set_log_categories	TODO: dynamic log levels: https://docs.rs/tracing-subscriber/latest/tracing_subscriber/reload/index.html
/update	TODO: update cuprated?
generateblocks	TODO: this is only supported on monerod's --regtest, will cuprated have --regtest?
flush_cache	TODO: will cuprated have m_invalid_blocks? Should this only flush the txpool?
sync_info	TODO: overview: #320 (comment)

Not supported

This table describes RPC calls which exist in monerod but will not be supported in cuprated.

This may mean they return a 404 or return some special error message that indicates it isn't supported.

RPC method/endpoint	Reason
/start_mining, /stop_mining, /mining_status, /set_log_hash_rate	cuprated will not include a miner
/get_info, /start_save_graph, /stop_save_graph	Deprecated

[dimalinux]

I'd put in a vote for supporting a --regtest flag. When I was working on ETH<->XMR atomic swaps, we made extensive use of both the --regtest flag and generateblocks in our tests. If you are writing client RPC libraries and other tooling, it is also very useful to spin up a test instance for tests to query. I'm assuming it would be less work and code to maintain than having a simulator like Hardhat for Ethereum.