vat-bank.js Exo nonce guards cause failures
#10928
Comments
|
@turadg, your #10929 (comment) made me realise that I was wrong. Digging further into this, I found that Thus, I gave bad advice in #8544; I know now that nearly all bridge actions are It's unfortunate that we may encounter loss of precision in the bridge messages. If we instead decide on diff --git a/golang/cosmos/x/vbank/vbank.go b/golang/cosmos/x/vbank/vbank.go
index 1a0ad037cd..90ee6e7b7d 100644
--- a/golang/cosmos/x/vbank/vbank.go
+++ b/golang/cosmos/x/vbank/vbank.go
@@ -69,7 +69,7 @@ func (vbu vbankManyBalanceUpdates) Swap(i int, j int) {
type VbankBalanceUpdate struct {
*vm.ActionHeader `actionType:"VBANK_BALANCE_UPDATE"`
- Nonce uint64 `json:"nonce"`
+ Nonce uint64 `json:"nonce,string"`
Updated vbankManyBalanceUpdates `json:"updated"`
}
Thoughts? |
|
I see. I think it comes down to whether we can change the serialization. If it's number, then the guard and types have to honor that. But as you point out it the loss of precision is a potential problem. Is it feasible to make changes to vbank.go to always encode as string? Let's discuss the trade-offs with other stakeholders. |
|
I'm also hitting this issue in cleaning up the upgrade 19 to My problem goes away. I'll wait to see here what the correct solution is. |
|
From discussion: |
|
What can I include in the update to upgrade-19 tests, which I'm working on now? I'd like this to be cleaned up before people want to start the release process for U19, which is supposed to follow close on the heels of U18a. I currently have the guard allow |
Describe the bug
When a
VBANK_BALANCE_UPDATEis sent fromagdto cause a vpurse balance update, it fails instead with a logged error.To Reproduce
Steps to reproduce the behavior:
DEBUG=SwingSet:vatv14: Error updating balance ...
Expected behavior
No error.
Platform Environment
git describe --tags --always) agoric-upgrade-16av-1785-g3d64bee5b5Additional context
I traced the error to the
BalanceUpdaterIinterface guard invat-bank. The change in #8544 made the formerundefinednonce (which had successfully passed the guard in the past) become a Golang int64 encoded as a JSnumber(which the guard was unprepared to accept). Both values were correctly handled by theupdater.updatemethod, but the guard failed to accommodatenonce: numbervalues.The text was updated successfully, but these errors were encountered: