Caching api prices to lower credits usage

[stormsson]

It's my impression that the calls are being made for each test execution;

While this is extremely useful the closer you get to the go-live, it's very credit consuming on all the previous phases.

Disabling the reporting totally could lead to very costly implementation not being noticed in time.

Is there the possibility to add a caching like 1 fetch every X minutes instead ?

[cgewecke]

In your design would the gas reporter need to know when the last hardhat test command was run? (I'm not sure it should track state like this)

One way to manage this on your end would be in hardhat.config.ts with environment variables. You could have a test command in npm scripts that looked like:

"test:gas:prices": "PRICE_DATA=true hardhat test",

and set the coinmarketcap and any other rate-limited data options conditionally

// hardhat.config.ts
gasReporter: {
 ...
 coinmarketcap: (process.env.PRICE_DATA) ? `${process.env..CMC_API_KEY}` : undefined
}

[stormsson]

Hi, thank you for the quick response;

I see the tracking of the request from another perspective: not when the last test suite was run, but when the last request to the pricing service has been made.

I have already setup the kind of condition you mentioned but this will probably cause the price reporter to be off for very long intervals before actually checking the prices: this could lead to long times before noticing that the implementation is very expensive.

--
The rationale behind this request is that from my PERSONAL experience realtime gas price checking during test time is not very valuable: even if it was once / twice every hour it would be great because what I usually need to report to my stakeholders is a pricing metric that is known to be very volatile due to how crypto works.

Basically in my opinion I fall in this possible scenarios:

• gas prices stay similar during testing time => realtime fetching does not provide much added value
• gas prices are very volatile => there is a valuable info the first time the data is fetched, but afterwards again the next test could give a totally different value so the reliability of this information is not very high.

[cgewecke]

not when the last test suite was run, but when the last request to the pricing service has been made

I see... so the reporter would cache timestamped prices in a local file (e.g .coinmarketcap.cache.json) and load from / save to there.

this will probably cause the price reporter to be off for very long intervals before actually checking the prices: this could lead to long times before noticing that the implementation is very expensive.

Ok, that makes sense - I think the case you've made here is reasonable.