Closed mhofman closed 4 months ago
So far the activityhash written by swingset seems to match, so we'll need to compare the cosmos stores instead.
The problem is int vs. number typing by XS in vat 47 (i.e., analogous to #7829):
< ["snapshot.v47.966758","{\"vatID\":\"v47\",\"snapPos\":966758,\"hash\":\"8db6e1dfc421dd108a00327cedf6321c88b2c6d2a8e8a898b241edc58bceb4de\",\"inUse\":1}"]
---
> ["snapshot.v47.966758","{\"vatID\":\"v47\",\"snapPos\":966758,\"hash\":\"84e306c37158b1746c82b9764b445b1aca965067539452feef837d3207ad58dd\",\"inUse\":1}"]
--- snapshot.v47.966758-good.dump 2024-06-28 18:45:51.112200024 +0000
+++ snapshot.v47.966758-nodes-guru.dump 2024-06-28 18:46:33.543477061 +0000
@@ -751232 +751232 @@
- [00324382] [ ] ____S___ integer = 100000000
+ [00324382] [ ] ____S___ number = 1.00000000000000000000e+08
We have verified that the xsnap-worker binary of the validator never rebuild because of #9614 so it included different behavior. While https://github.com/Agoric/agoric-sdk/issues/7829 was fixed, the final fix relied on some env variables to the make file which never applied.
Describe the bug
Nodes.guru performed u16 on their devnet node, and it AppHashed in the upgrade block.
To Reproduce
See swing-store export
Expected behavior
No app hash
Platform Environment
Some validator production environment, with a checkout of
agoric-upgrade-16-rc0
over an existingagoric-upgrade-15
repo, without agit clean
being performed.Additional context
The assumption right now is that because the checkout wasn't clean, some bundles ended up slightly different, and resulted in different swing-store data in IAVL.
Screenshots
https://snapshots.nodes.guru/agoricdev-23/swing-store-export.tar.zst