-
Notifications
You must be signed in to change notification settings - Fork 302
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
pmonitor: create client activity monitor #4844
Conversation
We just shipped the pcli-migrate-balance functionality (#4831), which enables full-wallet transfers, based on FVK. The |
0af76e5
to
7316cda
Compare
Sounds like this will be wrapped up or close this week, and since this is a read-only op, whoever reviews this should be sure to test against both testnet and mainnet. I can help generate a list of FVKs and checking the implementation should be straightforward from there. |
status: this now has support for migrated accounts, but needs testing before marking ready for review |
I'll take a first pass at review here, confirming that the tool 1) correctly identifies when accounts have been spent out of; and 2) supports the pcli-migrate-balance flow. |
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.
In terms of functionality, the tool appears to work well: in all the testing I've done, it correctly notates when balance is absent. Still more interactive testing to perform, but the implementation seems sound!
UX-wise, however, the tool obscures detection of misbehavior: any indication of a misbehavior is likely lost to scrollback in the default stdout, where there are more than, say, 5 FVKs to scan. Worse, the tool exits 0 regardless of whether misbehavior was detected. Suggestions to resolve:
- emit a "summary" message at the end of the
audit
run, notating explicitly if any accounts were found to have funds missing; - designate a specific exit code, e.g.
10
, for signaling that misbehavior was detected; that will allow the tool to be run in headless environments on a schedule, without resorting to string parsing; - (optional) convert the per-account messaging to tracing-subscriber statements, subject to RUST_LOG tweaking, to enable focusing on the summary message.
I left some in-line comments throughout, and also pushed up a script I've been using locally to test on a devnet. The biggest complaint I have about the technical bits are that the tool assumes it can cargo run --bin pcli
, which I'd prefer to address before merge.
crates/bin/pmonitor/src/main.rs
Outdated
} | ||
|
||
// Invoke pcli to initialize the wallet (hacky) | ||
let output = ProcessCommand::new("cargo") |
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.
Let's not assume that we have a full rust env and the git repo relative to the cwd for the command. Once the pmonitor
binary is built, it should have everything it needs to interact with external services and perform the check, regardless of where it's executed.
Looks like not everything we need is already pub
in pcli, but could be. Also willing to default to calling pcli
directly, rather than cargo run --bin pcli
, because then we can at least error out if not found and provide a helpful error msg.
height_created = excluded.height_created, | ||
address_index = excluded.address_index, | ||
source = excluded.source, | ||
height_spent = excluded.height_spent, |
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.
Note to self: there's whitespace trimming in these SQL statements, but also a substantive schema change below.
@@ -54,7 +54,8 @@ CREATE TABLE tx ( | |||
tx_hash BLOB PRIMARY KEY NOT NULL, | |||
tx_bytes BLOB NOT NULL, | |||
block_height BIGINT NOT NULL, | |||
return_address BLOB | |||
return_address BLOB, | |||
memo_text TEXT |
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.
Schema change! This breaks existing clients. Testing locally against testnet, I do indeed see the error message:
Error: can't load view database created by client version 0.80.5 using client version 0.80.5: they have different schemata, so you need to reset your view database and resynchronize by running pcli view reset
That's probably tolerable for a point-release, but we should be careful about downstream consequences. I'm thinking in particular of relayers like hermes
, which will likely fail when their deps are upgraded to a more recent view crate. I see we already merged a schema change in #4801 so we'll need to accommodate for the change already anyway. Relevant for rebasing the hermes fork, cc @zbuc.
crates/bin/pmonitor/src/main.rs
Outdated
if total_um_equivalent_amount < genesis_um_equivalent_amount { | ||
println!("✘ Unexpected balance! Balance is less than the genesis balance"); | ||
} else { | ||
println!("✅ Expected balance! Balance is greater than or equal to the genesis balance"); |
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.
Love the emojis, makes the wall of text a bit easier to scan visually. I only tested with 10 FVKs, though, and most of the relevant content was off the screen. Maybe tracing
statements would be more appropriate here.
cdcb279
to
45b91cd
Compare
Rebased on latest main, and added a handful of commits. Logging is now more verbose, but still TK are summary message and custom exit codes. During testing, I noticed that the tool will report an error if an account was migrated: we should refactor the audit logic to continue searching the migrated account, without reporting an error, or else explicitly state that a new migration was detected and therefore the tool should be rerun. |
Previously if an FVK was in the monitoring list that did not have a genesis allocation, we'd bail out. Instead, let's just note that its genesis balance is 0, and continue on.
Prefers `tracing_subscriber` logging over standard `println` messages, so that verbosity of output is customizable. Sorts the deps in pmonitor manifest. refactor: remove unwraps
Pretty sure this is strictly necessary: in order to detect the substring message in a memo text, we must perform the sql query via `sqlx` by providing wildcard characters like `%`. Updated query calls and associated docstrings.
The mismatch between view db filenames was causing some confusing behavior. Updated for consistency between both pcli and the pmonitor view service.
Uses `colorize` dep for pretty-printing human-readable message.
Adds automated testing of common use cases for the `pmonitor` FVK audit tool. The cargo tests are adapted from a one-off bash script written to aid in review of the original pmonitor PR. ci: add pmonitor integration workflow ci: adjust smoke concurrency ci: load rust cache
3fe1ed1
to
eec9d25
Compare
Looking great. I added some tests, and made some changes to implement the requested features, namely 1) summary message at end of run, and 2) exiting non-zero on failure. Example output from passing
|
Describe your changes
This PR adds a tool
pmonitor
that will enable one to monitor the activity of a list ofFullViewingKey
sPlan:
pmonitor
(because we need to use pclientd or pcli which assumes a single view key)FullViewingKey
sIssue ticket number and link
Will close #4832
Test
cargo run --bin pmonitor init --fvks test.json --grpc-url https://yourtestnetrpchere.example.com
Expected state: you should have in your
zone.penumbra.pmonitor
home directory (stored next to wherever your pcli default homedir is, so on my Macbook it's"/Users/redshiftzero/Library/Application Support/zone.penumbra.pmonitor"
) a:cargo run --bin pmonitor audit
:This will first sync all the wallets, then check the balances. Subsequent executions of the
audit
command will start with the state from the previous run.Note: To reset after testing:
cargo run --bin pmonitor reset
Checklist before requesting a review
If this code contains consensus-breaking changes, I have added the "consensus-breaking" label. Otherwise, I declare my belief that there are not consensus-breaking changes, for the following reason: