warp-contracts/warp

[BUG] Unable to retrieve tx. 404. undefined

balthazar opened this issue · 1 comments

balthazar commented

For a lot of contracts, I'm getting the above error.

At first I was seeing it and it made sense, for example with -xpuaVILHnSxMgYX3Oq1l0WKU1QBZjRT5LNmALZd7iA since the associated Contract-Src seems to be missing from the chain. This other interaction vLxXRooPhRxz4FGp0ZWihT3sGubDxEN0BysLHf0Y40I also appeared normal to fail given this time the contract itself was absent.

However, I am getting the same error for a lot of contracts like the following:

  • K3YIONC0GOHu-9FRWNILpLJvJ1egMTxeJhKJwNTEo2U
  • XIutiOKujGI21_ywULlBeyy-L9d8goHxt0ZyUayGaDg

Which do not appear to have any issue. I also computed the state of the later (Xluti) locally, and it worked fine so I'm guessing it might be due to a rate limiting of some kind.

Specs:

  • OS: Amazon Linux 2
  • Node.js version: 18
  • warp-contracts SDK version: 1.4.9
  • plugins: warp-contracts-plugin-vm2@1.0.2 warp-contracts-sqlite@1.0.1

Possibly related to #251

ppedziwiatr commented

Pasting answer from Discord here as well, for transparency ;-)

Two things here:

  1. it's weird that you can't download the data from the Warp GW itself - this indeed might be due to rate limitting, which we've had to turn on since we've been spammed with a LOT of requests. The default Contract loader in the SDK tries to first hit the Warp GW - if that fails (and it probably does due to 429 in this case), it fallbacks to default Arweave Gateway Loader - but this one works currently only for the direct L1 deployments.

Can you please retry 1, 2 or 5 of those contracts that failed and see how it goes?

  1. The mapping for the 'old' format (the one, that was used before the nested bundles were introduced - it basically wraps the original Arweave tx, signed by the client - in a data item - hence the 'double' ids - one of the original arweave transaction, one of the data-item, that wraps the Arweave transaction) is kept in the Uploader-Tx-Id tag of the data-item, eg:
image

Contract source with original tx id -Cww_UP4oRKriqLg9vaPbEFZFIT7T8Y2NnpxxhHlgUg and data item id: fxh9baiB30OUzFFLHYvC5bHVhDx-L1epbg3EF7-B3Wg: https://sonar.warp.cc/#/app/source/-Cww_UP4oRKriqLg9vaPbEFZFIT7T8Y2NnpxxhHlgUg

has the tags Uploader-Tx-Id set to -Cww_UP4oRKriqLg9vaPbEFZFIT7T8Y2NnpxxhHlgUg. This tag allows to find such transaction by its 'original' tx id.

The 'new' (introduced 2 or 3 months ago) nested bundle format removes the need for this double id mapping and all the data items can be easilly retrieved by their original ids.

The full documentation for the old format can be found here: https://academy.warp.cc/docs/sdk/legacy/bundled-contract-format-legacy#resulting-transaction-structure

Possible solutions:

  1. We can turn off rate limtting for now - all those contract loading-related requests are posted to the replica instance - worst case scenario the replica will die 🤷‍♂️
  2. We can add another fallback in the contrcts loading mechanism - basically add ability to use the Uploader-Tx-Id in certain scenarios.