Page MenuHomePhabricator

[chronik-client] Update GenesisInfo to return hex string for data key of ALP tokens
ClosedPublic

Authored by bytesofman on Sun, Nov 24, 12:42.

Details

Summary

This matches existing patterns in chronik-client. IMO we should stick to hex strings for API returns. API returns for tokens -- esp GenesisInfo -- needs to be cached as it never changes. Caching Uint8Array is complicated because it is not JSON. But hex strings are easy.

ecash-lib has available toHex and fromHex methods that make conversion easy depending on dev needs.

auth as a Uint8Array would require special handling in Cashtab's existing caching mechanism if we do not make this change.

Test Plan

CI tests

Event Timeline

Failed tests logs:

====== ALP: TxBuilder P2PKH ALP.ALP TxBuilder P2PKH ALP ======
AssertionError: expected { …(4) } to deeply equal { …(4) }
    at Context.<anonymous> (tests/alp.test.ts:121:58)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)

      + expected - actual

       {
         "genesisInfo": {
           "authPubkey": "03040506"
      -    "data": "01020304"
      +    "data": "1,2,3,4"
           "decimals": 4
           "tokenName": "ALP Token Name"
           "tokenTicker": "ALP TOKEN"
           "url": "https://example.com"

Each failure log is accessible here:
ALP: TxBuilder P2PKH ALP.ALP TxBuilder P2PKH ALP

tobias_ruck added a subscriber: tobias_ruck.
tobias_ruck added inline comments.
modules/chronik-client/README.md
117

This is a breaking change so should require a 2.0.0

modules/chronik-client/test/integration/token_alp.ts
212–214
This revision now requires changes to proceed.Sun, Nov 24, 22:25
bytesofman added inline comments.
modules/chronik-client/README.md
117

technically true (and also for ecash-lib, right?)

I think it's early enough days for ALP to keep this at the patch level for now. I'm ok with major-version bumping ecash-lib and chronik-client but it's more letter-of-the-law than spirit.

bytesofman marked an inline comment as done.

update test

tobias_ruck added inline comments.
modules/chronik-client/README.md
117

But if there's anyone using this field already (on 1.4.x), a new release on npm would automatically break their software.

I don't really see the problem with bumping the version to the "correct" semver value? It's not like we'll run out of numbers or so. If there's another breaking change later, we can bump the version to 3.

Not trying to be pedantic, just don't really see what problem is being solved by just bumping it as a patch version instead of major version.

This revision now requires changes to proceed.Mon, Nov 25, 01:00

major version bumps and readme/changelog updates

This revision is now accepted and ready to land.Mon, Nov 25, 01:54