Node http endpoints and handlers

[wi-ski]

Change Summary & Context

The following changes implement the routes outlined in the specification here: https://github.com/handshake-org/hsd/issues/142#issue-431258916

This PR is intended to be tested using this branch of hs-client:

• Branch: https://github.com/wi-ski/hs-client/tree/node-http-routes
• PR: https://github.com/handshake-org/hs-client/pull/11 for HSD.

They are covered by tests here: https://github.com/handshake-org/hsd/pull/168/files#diff-bbe506ab5582252a30d6872d35fd8ce6L21

[wi-ski]

Hey @tynes we spoke about landing these changes are separate PRs. But there were some consistency/non-determinism issues I thought we should chat about first!

[chjj]

Good work. This is probably a good start to adding names to the rest API. Will investigate the other race conditions tomorrow.

[tynes]

@wi-ski - I have an open PR here for GET /info/name/:name https://github.com/handshake-org/hsd/pull/162

I'd happily close it if you got this PR cleaned up

[wi-ski]

@tynes - Sitting down to take a pass at this now. Quick question: You ok with these changes landing in a single PR? :angel:

[wi-ski]

@tynes @chjj - Hey dudes. I took a stab at getting an event-listening setup working but encountered some errors using the .on(...) method of the FullNode. I'm at a loss.

Additionally, I tried to implement various forms of a sleep-esque test util and found that it actually made the test pass less consistently. This has been a battle.

I can set aside some to see if there's a better way to listen for events. @tynes - If you feel like any of this usable, please have at it.

:thinking: I really was stumped, listening for events would just mysteriously error most of the time. Super frustrating \o.o/.

[wi-ski]

Oh oh, I didn't even mention - I cleaned up the PR in that I:

1. Swapped out the "named" methods that were being used on the updated hs-client (using .get(...) now)
2. Restored package.json

Is there a recommended way of "sleeping" that either of you have had success with btw?

[tynes]

A simple sleep function:

async function sleep(time) {
  return new Promise(resolve => setTimeout(resolve, time));
}

[tynes]

More useful helper functions by @braydonf

https://github.com/bcoin-org/bcoin/pull/748/files#diff-e169f8c8ca803ee76312e094ba6f17cbR105

common.event = async function event(obj, name) {
  return new Promise((resolve) => {
    obj.once(name, resolve);
  });
};

https://github.com/bcoin-org/bcoin/pull/758/files#diff-e169f8c8ca803ee76312e094ba6f17cbR105

common.forValue = async function(obj, key, val, timeout = 30000) {
  assert(typeof obj === 'object');
  assert(typeof key === 'string');

  const ms = 10;
  let interval = null;
  let count = 0;
  return new Promise((resolve, reject) => {
    interval = setInterval(() => {
      if (obj[key] === val) {
        clearInterval(interval);
        resolve();
      } else if (count * ms >= timeout) {
        clearInterval(interval);
        reject(new Error('Timeout waiting for value.'));
      }
      count += 1;
    }, ms);
  });
};

[boymanjor]

@tynes - Sitting down to take a pass at this now. Quick question: You ok with these changes landing in a single PR? 👼

@tynes @wi-ski I think this is fine as one, name related PR.

[codecov-io]

Codecov Report

Merging #168 into master will increase coverage by 0.65%. The diff coverage is 91.66%.

@@            Coverage Diff             @@
##           master     #168      +/-   ##
==========================================
+ Coverage   52.99%   53.64%   +0.65%     
==========================================
  Files         129      129              
  Lines       35773    35845      +72     
  Branches     6032     6043      +11     
==========================================
+ Hits        18957    19230     +273     
+ Misses      16816    16615     -201

Impacted Files	Coverage Δ
lib/node/http.js	55.8% <91.66%> (+6.5%)	:arrow_up:
lib/covenants/rules.js	73.04% <0%> (-0.15%)	:arrow_down:
lib/net/pool.js	24.22% <0%> (+0.04%)	:arrow_up:
lib/script/script.js	58% <0%> (+0.07%)	:arrow_up:
lib/net/peer.js	20.06% <0%> (+0.3%)	:arrow_up:
lib/blockchain/chaindb.js	64.1% <0%> (+0.37%)	:arrow_up:
lib/wallet/wallet.js	62.4% <0%> (+0.99%)	:arrow_up:
lib/wallet/nodeclient.js	80% <0%> (+1.42%)	:arrow_up:
lib/covenants/namestate.js	88.57% <0%> (+1.6%)	:arrow_up:
... and 4 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update cc1ef7a...231e30e. Read the comment docs.

[wi-ski]

Ok - extending the timeout for the test suite allowed for these to pass. Not ideal.

[tynes]

Can you mine less blocks? We don't want to dramatically extend the length of the test suite with just one set of tests

[wi-ski]

@tynes - Updates:

1. Using the mentioned event listening util.
   • Test pass seemingly consistently.
2. Mining fewer blocks.

Recent CI passed with longer test times requiring a little under 10 seconds to complete.

Hit me with your feedback when you can.

[wi-ski]

#bump. @tynes, anything I can do for this PR to help get it over the line?

[tynes]

@wi-ski thanks for the bump. Just left a few comments for you

[wi-ski]

Swinging back on this. Ill take a look into CI 🤔

[wi-ski]

@tynes #bump

[wi-ski]

@tynes: a. Addressed line length issues. b. The shape of the "proof" routes' response - I went with the:

      return res.json(200, {
        hash: tip.toString('hex'),
        height: height,
        root: root.toString('hex'),
        key: nameHash.toString('hex'),
        name: ns ? ns.name.toString() : null,
        ...proof.toJSON()
      });

approach. I think this achieves what I feel like you described as acceptable. It would be awesome to chat about that in more detail if you have any issues with it. c. Loops in the test - I left a note about wanting to avoid this, it feels premature. If you feel otherwise after me bringing that up, let me know!

[wi-ski]

@tynes bump <3

[wi-ski]

@tynes - Touching base on this. How are we looking?