LW-13062 Stake pool service

[iccicci]

Checklist

• JIRA - LW-13062
• Proper tests implemented
• Screenshots added.

---

Proposed solution

• Implemented client side stake pools services which fetches partial stake pools from BF bulk stake pools API and caches them for 1 day.
• Implemented client side StakePoolProvider.
• Refactored useQueryStakePools custom hook to take advantage of the new performances: removed the use of the paginator.

Testing

Manual testing

[lace-bot]

Allure Report

allure-report-publisher generated test report!

processReports: ✅ test report for 4ee15b34

	passed	failed	skipped	flaky	total	result
Total	33	0	4	0	37	✅

[DominikGuzei]

Please elaborate on why asyncFetchData is required 🙏 it seems like it's about not re-fetching while fetching is already in process? If so, the check for fetchingData could maybe be moved to fetchData itself?

[iccicci]

Ok.

[iccicci]

0359a41 should solve this

[DominikGuzei]

If we want to fire and forget an async function we could just call it without await 🤔

[iccicci]

Indeed it is called without await, sorry, but I can't get the point.

[DominikGuzei]

@iccicci my point is that we don't need a separate function to do that …

• the check for fetchingData could be moved into fetchData itself (so it never fetches twice)
• the error logging could be moved into fetchData itself (by catch) and if we want to store it we could return it as Promise.reject(reason)

To me, the current interaction and dependency between fetchData and asyncFetchData is confusing. I'm in favor of defensive programming where fetchData (itself) ensures consistent results no matter how often or where it gets called from.

[DominikGuzei]

@iccicci In general i think this kind of complexity warrants unit tests as it is hard for me to tell if the code does what it is supposed to do. Here are a few suggestions:

• Move the inline functions within initStakePoolService (especially fetchData) outside and write exhaustive unit tests for it
• Write at least 1-2 integration tests (happy path + error case) for the initStakePoolService to make sure the complete setup works as expected.

[iccicci]

Hi @DominikGuzei , 5fae7ea adds tests which cover all the cases coming to my mind.

[mirceahasegan]

Maybe get rid off poolDetails and use it directly from cachedData.poolDetails?
They represent the same data and keeping them in sync is error prone.

-   let poolDetails: StakePoolCachedData['poolDetails'] = new Map();
.....
-      for (const [poolId, { lastFetchTime }] of poolDetails)
+      for (const [poolId, { lastFetchTime }] of data.poolDetails)

[iccicci]

cachedData and poolDetails are actually two distinct sets of data:

• the first one stores all the global data and it is entirely refreshed by fetchData;
• the second stores details for those stake pools which are queried by id, the details the bulk API do not provides; each entry has its own expiration date.

Probably the confusion comes from the fact I added poolDetails to cachedData with the purpose to save all the data with a single storage key. Probably it would be better to store the two distinct data with two distinct storage keys, this should help the reader understanding they are distinct and should reduce the confusion.

[iccicci]

Another source of confusion is I decided to have two caches each with its own expiry.
After meeting with @mirceahasegan we agreed what follows; since there is not so much benefit from the separated expiration of details, for the sake of simplicity, better to have a single cache expiration: when it expires, details will be erased as well.

[mirceahasegan]

Excellent work @iccicci 🦾

[DominikGuzei]

Thanks for adding exhaustive unit tests and code improvements @iccicci 🎉
There is only one doubt left on my side: there is currently no way for the user of the service api to know if the data is coming from cache or if its the latest "real" data … this might not be critical but i don't have a full overview of the v1 staking environment to make a judgement on this.

[przemyslaw-wlodek]

Great work @iccicci ! 🚀

[sonarqubecloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud