api3dao / airnode-starter Goto Github PK

Currently, the tutorial uses an Airnode deployed on AWS as a serverless function. This has a few downsides:

• Creates some friction by requiring the user to create an AWS account
• Not trivial to make this work with a local chain (#31), you would need to expose a public endpoint to your locally run Hardhat Network
• The node logs to CloudWatch and the user finds it difficult to find these. A local, containerized node logs to the terminal, which is much more beginner-friendly

The tutorial should use Airnode client by default and provide serverless Airnode instructions as an alternative flow.

We need a v0.1.0 for airnode starter. It's currently being worked on at the 0.1.0_setup branch.

It has been reported that it's difficult to follow the flow on Windows because things don't work. This is likely to do with UNIX path convention being hardcoded in some scripts. We need to do the modifications so that the repo is portable.

Currently, the tutorial uses Ropsten, but both the chain and its faucets are very unstable. The tutorial should use Hardhat Network (Ganache alternative) by default and provide public chain instructions as an alternative flow.

When making requests on arbv4 sometimes it seems like the request didn't work because it can stall indefinetely waiting for fulfillment or even return a price of zero. When I go back and try to see if the request was fulfilled correctly though by querying for the requestId again a second time it is always correct.

Sometimes I would notice that the request would be fulfilled correctly and the ethers filtering picks it up but when querying past events with web3 it cannot find the ClientRequestFulfilled event yet for a very short time. So there seems to be issues with querying arbitrum events with both Ethers and Web3, with them disagreeing on if an event was emitted sometimes or other times ethers just misses the event completely.

So overall the issue seems to be with latency and emitted event querying on arbitrum, airnode works fine if you just wait a few seconds after fulfillment to query the request output value (sometimes it works instantly just fine though). This can end up in the airnode-starter test appearing as if it didn't work.

If you let me know a way to debug this better happy to work some more on it.