[Cashtab] [Alias] pt 18 - Pre-prod update - Remove residual dev logs
ClosedPublic
Actions

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

Details

Reviewers

bytesofman

Group Reviewers

Restricted Project

Commits

rABC8a1bdb0e2736: [Cashtab] [Alias] pt 18 - Pre-prod update - Remove residual dev logs

Summary

T2551

Remove the temporary console logs for reviewer from previous stacks. Some are retained as prod logs due to usefulness.

[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

verify the changes below are specific to removing dev logs
npm test
enable Alias in ticker
npm start
register a new alias, ensure the (pending) logic is intact and upon new block the confirmed alias is updated in Alias.js

Diff Detail

Repository

rABC Bitcoin ABC

Lint

Lint Not Applicable

Unit

Tests Not Applicable

Event Timeline

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

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

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

emack edited the summary of this revision. (Show Details)Mar 29 2023, 02:12

Harbormaster completed remote builds in B22799: Diff 39009.Mar 29 2023, 02:13

green with nit (see comment)

also got this:

it updated on the next block though.

imo this is probably what happens most of the time. the /aliases endpoint on the server is itself updated by a chronik websocket tx, which the server may miss, or may take longer than cashtab's simple API request for the server to update the latest aliases. I have an endpoint that brings back only "after this blockheight." I could pretty easily make another one that only brings aliases after "aliasCount" aliases. This would improve performance.

Anyway, that is a server-side optimization and not relevant to this diff. But we don't want to do our prod launch using the /aliases endpoint. So think about what would be most useful for implementing in cashtab.

The server currently has both processedBlockheight and registeredAliasCount available at https://aliasdev.etokens.cash/state e.g. {"processedBlockheight":785354,"processedConfirmedTxs":718,"registeredAliasCount":426,"registrationAddress":"ecash:qp3c268rd5946l2f5m5es4x25f7ewu4sjvpy52pqa8"}

so an easy way to optimize would be to refactor getLatestAliases() so that it only asks for more aliases if /state registeredAliasCount is higher than Cashtab's. Then hit the endpoint specific to registeredAliasCount (which I still need to build).

web/cashtab/src/hooks/useWallet.js
1220 ↗	(On Diff #39009)	I think it's okay to keep this log. Since it's here, go ahead and add the count, i.e. console.log(`Server and cache both have ${onchainAliasCount} aliases. Cashtab alias cache is up to date.`)