namada
namada copied to clipboard
anoma
CLI told me I had to report this bug
Well, well, well, that's a first. The CLI told me I had to report this bug 😅. This attempted to divide by zero.
namada client balance --owner "zvknam1qynmxyf5qqqqqq983j0nwgsc8zf0jhglrq3x49y05vz3vdhlwcw9taldce6apv73e3g8mpn57afyqdnkh8dpmp7v962l24m69f8aynp7sa02jsf93ftaehmlwtj9ak7hply4c93862sahqtprluapxda5p5x3gx4k6wzqedjuu8yhtyk5paxedw6gpfhfsatr96jeqh9tjh2258xtrnyz0f2pddhsr3ms6lwkywaphy687uvcnwc06jd32zu375437xe6p2yx6ets6c07r988"
Result:
Last committed epoch: 79
converting current asset type to latest asset type...
Asset threshold of selected conversion for asset type bfe4922fe3da46887eaeedfc37dfd286c11f961cc37dbe285dd08dc241539020 is 0, this is a bug, please report it.
The application panicked (crashed).
Message: attempt to divide by zero
Location: /home/runner/work/namada/namada/crates/sdk/src/masp.rs:1474
Backtrace omitted. Run with RUST_BACKTRACE=1 environment variable to display it.Run with RUST_BACKTRACE=full to include source snippets.
bfe4922fe3da46887eaeedfc37dfd286c11f961cc37dbe285dd08dc241539020 must be a specific asset, because I cannot replicate this error. What could that asset be?
In my case when supplying a Viewing Key it keeps doing this:
Last committed epoch: 79
converting current asset type to latest asset type...
converting current asset type to latest asset type...
converting current asset type to latest asset type...
converting current asset type to latest asset type...
converting current asset type to latest asset type...
converting current asset type to latest asset type...
converting current asset type to latest asset type...
converting current asset type to latest asset type...
@zenodeapp What version were you running?
Hey, this was after the hardfork so: v0.32.1.
It seems that the conversions in the se ended up in a valid state, so re-syncing from scratch should work although it is not ideal. Unfortunately, I don't think we are going to be able to reproduce this error. We've tried to strengthen checks on the client side to prevent this error from happening in PR #3195. I think that's the best we can do for now.