-
Notifications
You must be signed in to change notification settings - Fork 0
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
Fix get_account_ids
#11
Conversation
src/store/accounts.rs
Outdated
.expect("no binding parameters used in query") | ||
.map(|result| { | ||
result | ||
.map_err(StoreError::ColumnParsingError) | ||
.map(|id: u64| AccountId::try_from(id).expect("account id is valid")) | ||
.map(|id: i64| AccountId::try_from(id as u64).expect("account id is not 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.
Just to be clear, in the Miden projects (not sure but it could be the norm as well) the expect()
messages is usually why you expect the statement to be valid. For instance:
let timestamp = SystemTime::now()
.duration_since(UNIX_EPOCH)
.expect("we are after 1970")
.as_millis() as u64;
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.
Oh, I thought it was a typo. Thanks for the clarification
src/store/accounts.rs
Outdated
.query_map([], |row| { | ||
let row: i64 = row.get(0)?; | ||
Ok(row) | ||
}) |
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 these changes can be removed since id
will be inferred to be i64
because of the following map
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.
you're right! I left it as it was before
…aBA-fix-endpoint-to-get-account-ids
closing as I opened the same PR pointing to the forked repo |
Motivation
When testing with the cli, I found an error when running:
Changes
Row
and cast it to u64 afterwards (I saw this was being done for other ids)Steps to reproduce
It might take a few tries because it will depend on the generated faucet id. For each try do:
rm target/release/store.sqlite3 cargo run --release --features testing -- mock-data cargo run --release --features testing -- account new fungible-faucet -t TEST -d 10 -m 10000 # It should raise here cargo run --release --features testing -- sync-state sync-state