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)

Most upvoted comments

The tx_bytes return from calling said type (sui_transferObject, etc,) and just slice off the last 97 bytes as I provided that hint above. Hack really, but let’s call it a “hint” 😃

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.

I construct from bottom up using Python implemented BCSTransactionKind etc. etc.

With a local transaction builder, you should just be able to construct only the single transaction kind (without any byte manipulation)

@amnn @tnowacki @666lcz sui_transferSui is an odd one when inspecting.

In the normal call, a sui_object_id is identified (required field) however; The BCS (tx_bytes) returned does not contain the coin and If I construct the BCS, the TransferSui only contains the recipient and (optional) amount

Why no sui_object_id ObjectRef ?

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

  1. Decode from base64
  2. Encode (back to base64) all of step 1 but the last 97 bytes. These 97 are the budget and gas objects
  3. Use the new base64 string as input of bytes in the 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.