sui: [bug] sui_devInspectTransaction failing on 0.24.0 devnet
In order to accommodate the new input to the subject RPC call, I have BCS serialized the SingleTransactionKind(PaySui) whichi produces the following bytes (put in u8 list for convenience):
[0, 5, 1, 20, 87, 32, 11, 222, 234, 36, 110, 94, 59, 37, 198, 115, 35, 47, 235, 70, 8, 226, 156, 93, 176, 2, 0, 0, 0, 0, 0, 0, 32, 155, 239, 255, 8, 3, 94, 134, 142, 215, 65, 22, 72, 140, 168, 45, 239, 22, 80, 186, 104, 63, 8, 70, 178, 190, 97, 159, 100, 116, 173, 41, 52, 1, 20, 212, 120, 254, 173, 89, 93, 24, 147, 228, 177, 174, 173, 38, 105, 189, 176, 159, 224, 227, 15, 1, 64, 66, 15, 0, 0, 0, 0, 0]
And the base64 string from above bytes:
AAUBFFcgC97qJG5eOyXGcyMv60YI4pxdsAIAAAAAAAAgm+//CANeho7XQRZIjKgt7xZQumg/CEayvmGfZHStKTQBFNR4/q1ZXRiT5LGurSZpvbCf4OMPAUBCDwAAAAAA
But I am getting:
Inspect failure -> {'code': -32000, 'message': 'invalid length 0, expected an byte array of size 32'}
There are more details in forum
Also, if I just take the tx_bytes result of calling sui_paySui
and feed the tx_bytes from that into devInspectTransaction, it fails as well.
About this issue
- Original URL
- State: open
- Created a year ago
- Comments: 26 (13 by maintainers)
These are the RPC transaction builders right? I’m not as familiar with that space, but we have some further cleanup to help support full transaction payloads.
With a local transaction builder, you should just be able to construct only the single transaction kind (without any byte manipulation)
transferSui probably should be banned in the current iteration of dev_inspect, since there really isn’t a gas coin to transfer. It was banned in some of the Pay variants due to some implementation quirks for those transactions.
Though it should all work just fine when programmable transactions come along
@jaredcosulich OK. So there is another trick that works on RPC: Take the tx_bytes from the submitted (not signed)
sui_moveCall
sui_devInspectTransaction
It’s a hack but it currently works.
@FrankC01 @PaulFidika sorry for the late response since the team is busy at an offsite this week! Thank you for all your valuable feedback and I will try my best to improve the interface and address the concern ASAP (ideally before the next DevNet release)
However, I haven’t been able to repro this on DevNet in my first attempt. Here’s my code and output, including the raw txn input, Transaction kind, BCS bytes, Base64 encoded string, and DevInspect result. @FrankC01 do you mind giving me the raw transaction input?
Regardless I will keep investigating after the offsite ends tomorrow
Yep, I get you, but Chris might have visibility on how the serialization changed in v0.24.0, as he will have had to deal with any changes for the TS SDK as well.