bbenligiray
commented
3 years ago Thanks for the write-up. I think the main problem is that subscription patterns (.once() in https://github.com/api3dao/airnode-starter/blob/main/scripts/make-request.js#L39) always end up suffering from some edge cases, which is why Airnode is designed to poll for requests, that's just more robust.
We can simply replace the line linked above to poll every second for the event instead, but there are a ton of other subscriptions in the @api3/airnode-admin package (to get the requester index after creating the requester, etc.) so it's not a complete solution. I think airnode-starter appearing to fail sometimes without actually failing due to an issue with Arbitrum that they may end up solving anyway is not a serious problem. Let's keep this issue open and see if it happens on other chains/to others on Arbitrum.
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.