[Cashtab] [Alias] pt 19 - Pre-prod update - Update getLatestAliases to use the State endpoint
ClosedPublic
Actions

Authored by emack on Mar 29 2023, 10:46.

Details

Reviewers

bytesofman

Group Reviewers

Restricted Project

Commits

rABC77400951809d: [Cashtab] [Alias] pt 19 - Pre-prod update - Update getLatestAliases to use the…

Summary

T2551

As part of performance optimization, this diff refactors getLatestAliases to use the new getAliasServerState (state endpoint) in aliasUtils.js to check whether local cached alias counts match the onchain alias counts. If they don't match, only then will Cashtab make a call to getAliasServerHistory (aliases endpoint) to retrieve the latest list of aliases.

[Cashtab] [Alias] pt 18 - Pre-prod update - Remove residual dev logs
[Cashtab] [Alias] pt 19 - Pre-prod update - Update getLatestAliases to use the State endpoint
[Cashtab] [Alias] pt 20 - Pre-prod update - Set final registration fees
[Cashtab] [Alias] pt 21 - Pre-prod update - Set final payment address and enable prod flag

Test Plan

enable aliases in ticker.js
npm test
npm start
assuming wallet cache is recent, the console log should display Server and cache both have 426 aliases. Cashtab alias cache is up to date. and note the alias count
register a new alias
upon new block, ensure the cache alias count does not match onchain alias count, refreshing aliasCache log is displayed in console
refresh the app and note the correctly incremented alias count matching for cache and onchain.

Diff Detail

Repository

rABC Bitcoin ABC

Lint

Lint Not Applicable

Unit

Tests Not Applicable

Event Timeline

emack created this revision.Mar 29 2023, 10:46

Herald added a reviewer: Restricted Project. · View Herald TranscriptMar 29 2023, 10:46

emack requested review of this revision.Mar 29 2023, 10:46

Harbormaster completed remote builds in B22804: Diff 39015.Mar 29 2023, 10:49

It's a good improvement to the current state of the app.

A separate but important issue: how does getLatestAliases behave when the server is down? It looks like right now it would just set the cache to nothing.

The appropriate response is to do nothing to the cache until you get a good response from the server. Since this is called 'on block' --- say the server is down for a day. We'd like Cashtab users to still use their cached aliases. They just wouldn't be able to use any aliases registered on that day.

More broadly -- how does Cashtab behave when the alias server is down?

In this case, we should support sending to cached aliases. But we should not support registering new aliases, as this could lead to conflicting transactions.

So, breaking this into tasks:

Ensure getLatestAliases does not impact alias cache if alias-server is down, i.e. if it the API response is not as expected T3061
Disable registering aliases if cached alias state is not the latest. This is true both if cachedAliasCount < serverAliasCount, and also if serverAliasCount is unavailable. T3062

This revision is now accepted and ready to land.Mar 29 2023, 17:48

Closed by commit rABC77400951809d: [Cashtab] [Alias] pt 19 - Pre-prod update - Update getLatestAliases to use the… (authored by emack). · Explain WhyMar 29 2023, 23:33

This revision was automatically updated to reflect the committed changes.

emack added a commit: rABC77400951809d: [Cashtab] [Alias] pt 19 - Pre-prod update - Update getLatestAliases to use the….