warp-contracts/warp

[BUG] Silent errors using `arlocal@^v1.1.63`

Closed this issue · 12 comments

erhant commented

Describe the bug
Latest Arlocal versions are buggy using Warp.forLocal.

Note that Warp uses a fixed arlocal version https://github.com/warp-contracts/warp/blob/main/package.json#L114 so this would not affect the tests as is.

I checked every version between yours (v.1.1.42) and the latest arlocal (v1.1.64) and here are my findings:

  • v1.1.48 & v1.1.49: Could not getPrice. Received: 500952894.59599996. Status: 200, OK
  • v1.1.61: I had a silent-error on deployment, which became apparent when I tried to make interactions to that contract & warp couldnt find the tx id. I couldn't reproduce this somehow.
  • v1.1.63 & v1.1.64: No errors from Arlocal or Warp, its just that no interaction actually takes place. I tried calling mine manually but did not work. For example I can update a contract state, and read it to see that it is still the initial state.

To Reproduce
Run Warp tests with said arlocal versions, but most importantly with the latest.

For context, I am using the following https://github.com/firstbatchxyz/hollowdb/blob/master/tests/set.test.ts test, which uses KVStorage as well but I doubt that has to do with the arlocal bug. My tests work with other arlocal versions as noted.

Expected behavior
The tests should pass.

Desktop (please complete the following information):

  • OS: macOS
  • Node.js version: 20.5.0
  • warp-contracts SDK version: 1.4.31
  • no plugins
ppedziwiatr commented

@erhant I'm not sure whether there is sth that Warp can do this about this? I rememeber I was trying to update ArLocal at some point - but our tests were failing - that's why it is still kept on this (I admit - fairly old) version.

Anyway, I'll try to run this on the latest ArLocal version and maybe check the ArLocal's logs...

erhant commented

Indeed this seems to be 100% on Arlocal's side. We probably have to wait for their side to fix, but would be nice to keep this issue open in case anyone else has the same problem when they install arlocal without a tag.

ppedziwiatr commented

It seems that interactions are stored, but for some reason not returned by the GQL endpoint - I'm in the process of the debugging it...

  • ❤️1
ppedziwiatr commented

@erhant , root cause described here: textury/arlocal#152 (comment)

erhant commented

awesome work man, sounds like an easy parameter-handling fix on their side! 💐

erhant commented

I wanted to help out on this, but I've never used GraphQL haha 😅

erhant commented

textury/arlocal@v1.1.62...v1.1.63 this may be the issue @ppedziwiatr.

They have changed from foo?.bar || undefined to just foo?.bar. When foo?.bar is null, v1.1.62 results in undefined but the latest ones remove that check so it stays null.

Probably Arweave expects undefined instead of null.

ppedziwiatr commented

textury/arlocal@v1.1.62...v1.1.63 this may be the issue @ppedziwiatr.

They have changed from foo?.bar || undefined to just foo?.bar. When foo?.bar is null, v1.1.62 results in undefined but the latest ones remove that check so it stays null.

Probably Arweave expects undefined instead of null.

good catch, should be a farily easy fix :-)

erhant commented

@ppedziwiatr do you think Warp should send undefined instead of null for that parameter?

ppedziwiatr commented

@ppedziwiatr do you think Warp should send undefined instead of null for that parameter?

I think that ArLocal should behave the same as the arweave.net/graphql endpoint.

Also, arweave.net does not work with undefined
image

  • 👍1
erhant commented

Closing the issue since arlocal has merged the fix (v1.1.65)

ppedziwiatr commented

I've upgraded our SDK to the latest version of arlocal