Add validator list RPC calls (RIPD-1541) #2242

bachase · 2017-10-09T18:46:48Z

In support of dynamic validator list, this changeset

Adds a new validator_list_expires field to server_info that indicates when the current validator list will become stale.
Adds a new admin only validator_lists RPC that returns the current list of known validators and the most recent published validator lists.
Adds a new admin only validator_sites RPC that returns the list of configured validator publisher sites and when they were most recently queried.

This builds on PR #2240, which is the first two commits in this changeset.

bachase · 2017-10-09T18:46:54Z

@HowardHinnant, I took some of your chrono changes in #2237 for use cdc7537

wilsonianb · 2017-10-09T21:57:58Z

src/test/jtx/TrustedPublisherServer.h

+
+}  // namespace test
+}  // namespace ripple
+#endif


No newline at end of file

wilsonianb · 2017-10-09T21:59:11Z

src/ripple/app/misc/impl/ValidatorList.cpp

+            std::forward_as_tuple(local),
+            std::forward_as_tuple());
+        // Config listed keys never expire
+		if (it.second)


#UnIndent2x

wilsonianb · 2017-10-10T06:19:02Z

src/test/rpc/ValidatorRPC_test.cpp

+            expiration,
+            1,
+            keys);
+        env.app().validatorSites().start();


I'm getting the same test failures as Travis:

#32 failed: ValidatorRPC_test.cpp(269) #33 failed: ValidatorRPC_test.cpp(273) #34 failed: ValidatorRPC_test.cpp(275) #35 failed: ValidatorRPC_test.cpp(277) #37 failed: ValidatorRPC_test.cpp(290) #38 failed: ValidatorRPC_test.cpp(291) #39 failed: ValidatorRPC_test.cpp(301) #41 failed: ValidatorRPC_test.cpp(304) #45 failed: ValidatorRPC_test.cpp(314) #46 failed: ValidatorRPC_test.cpp(317)

The site isn't being fetched here because ValidatorSite::start was already called when env was constructed.
The only workaround I've thought of is to use a new Env for this set of tests (and construct it after the site is up).

codecov-io · 2017-10-10T16:27:36Z

Codecov Report

Merging #2242 into develop will increase coverage by 0.09%.
The diff coverage is 93.2%.

@@            Coverage Diff             @@
##           develop   #2242      +/-   ##
==========================================
+ Coverage    70.11%   70.2%   +0.09%     
==========================================
  Files          689     691       +2     
  Lines        50800   50890      +90     
==========================================
+ Hits         35617   35726     +109     
+ Misses       15183   15164      -19

Impacted Files	Coverage Δ
src/ripple/app/misc/ValidatorSite.h	`100% <ø> (ø)`	⬆️
src/ripple/rpc/impl/Handler.cpp	`97.61% <ø> (ø)`	⬆️
src/ripple/app/misc/ValidatorList.h	`98.24% <100%> (-0.04%)`	⬇️
src/ripple/rpc/handlers/ValidatorListSites.cpp	`100% <100%> (ø)`
src/ripple/app/misc/NetworkOPs.cpp	`62.56% <100%> (+0.81%)`	⬆️
src/ripple/rpc/handlers/Validators.cpp	`100% <100%> (ø)`
src/ripple/app/misc/impl/ValidatorSite.cpp	`80.24% <89.47%> (+1.92%)`	⬆️
src/ripple/app/misc/impl/ValidatorList.cpp	`85.09% <92.3%> (+1.76%)`	⬆️
... and 6 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 cafe18c...9b6ce34. Read the comment docs.

mellery451

I'd like to see the hardcoded test port changed ...otherwise looks good to me

mellery451 · 2017-10-10T16:54:22Z

src/test/rpc/ValidatorRPC_test.cpp

+#include <test/jtx.h>
+#include <test/jtx/TrustedPublisherServer.h>
+
+#include <boost/format.hpp>


I don't see any evidence that this header is used...I might be missing something

mellery451 · 2017-10-10T16:55:11Z

src/test/rpc/ValidatorRPC_test.cpp

+
+public:
+    void
+    testPriviledges()


to be super nit-picky, this is mispelled (no 'd' in privilege) BUT I would not change unless you are messing the the code for some other reason.

mellery451 · 2017-10-10T16:59:41Z

src/test/app/ValidatorSite_test.cpp

-        http_sync_server server1(
-            ep1, ioService, pubSigningKeys1, manifest1, sequence,
-            expiration.time_since_epoch().count(), version, list1);
+        TrustedPublisherServer server1(


ioService (line 116) is now unused, FWIW

mellery451 · 2017-10-10T17:21:55Z

src/test/rpc/ValidatorRPC_test.cpp

+            expectedKeys.insert(toStr(key));
+
+        // Publisher site information
+        std::uint16_t constexpr port = 7475;


for tests particularly, I would opt for OS port selection - it helps avoids spurious failures related to ports in use. You can use port 0 in for the bind endpoint and then provide a way on TrustedPublisherServer to get acceptor_.local_endpoint() after listen has been called, which you then pass to clients (probably the simplest approach is just make acceptor_ public).

mellery451

👍

wilsonianb · 2017-10-13T04:06:07Z

src/ripple/app/misc/impl/ValidatorList.cpp

+        }
+    }
+
+    // Current validator keys


This seems redundant since it's always accompanied by the individual published lists from above.
What if we instead just list the trusted keys (from trustedKeys_)?

Agreed, that makes a lot more sense.

Call the JSON field validator_keys or trusted_validator_keys?

I like trusted_validator_keys better

wilsonianb · 2017-10-13T04:10:47Z

src/ripple/app/misc/impl/ValidatorSite.cpp

@@ -231,6 +232,9 @@ ValidatorSite::onSiteFetch(
                body["signature"].asString(),
                body["version"].asUInt());

+            sites_[siteIdx].lastRefreshStatus.emplace(
+                Site::Status{clock_type::now(), disp});


I think lastRefreshStatus should also be updated with ListDisposition::invalid in the else below in the case that we fail to parse the JSON.

wilsonianb · 2017-10-13T04:21:33Z

src/ripple/protocol/JsonFields.h

 JSS ( url );                        // in/out: Subscribe, Unsubscribe
 JSS ( url_password );               // in: Subscribe
 JSS ( url_username );               // in: Subscribe
 JSS ( urlgravatar );                //
 JSS ( username );                   // in: Subscribe
 JSS ( validated );                  // out: NetworkOPs, RPCHelpers, AccountTx*
                                    //      Tx
+JSS ( validator_list_expires) ;     // out: NetworkOps


also in ValidatorList

wilsonianb · 2017-10-13T04:30:33Z

src/ripple/rpc/handlers/ValidatorLists.cpp

+Json::Value
+doValidatorLists(RPC::Context& context)
+{
+    auto lock = make_lock(context.app.getMasterMutex());


Do we need the lock? (Same with ValidatorSites handler)

Good catch. I was just following other RPCs, but since the getJson calls are themselves safe, this is not needed.

wilsonianb · 2017-10-13T04:36:47Z

src/test/app/ValidatorList_test.cpp

+            BEAST_EXPECT(trustedKeys->listed(localCfgListed));
+        }
+
+        // Manifest published keys with expirations


~~Manifest~~

wilsonianb · 2017-10-13T04:37:10Z

src/test/app/ValidatorList_test.cpp

+            BEAST_EXPECT(
+                trustedKeys->load(emptyLocalKey, emptyCfgKeys, cfgKeys));
+
+            // Initially, no manifest has been published, so never stale


manifest --> list

wilsonianb · 2017-10-13T04:37:59Z

src/test/app/ValidatorList_test.cpp

+    void
+    testExpires()
+    {
+        testcase("Stale");


Consider "Expires" or "Expiration"

wilsonianb · 2017-10-13T15:53:17Z

src/test/rpc/ValidatorRPC_test.cpp

+                {
+                    // The current HTTP/S ServerHandler returns an HTTP 403
+                    // error code here rather than a noPermission JSON error.
+                    // The JSONRPCClient just eats that error and returns an


an --> a

wilsonianb · 2017-10-13T16:09:39Z

src/test/rpc/ValidatorRPC_test.cpp

+        // Publisher list site unavailable
+        {
+            // Publisher site information
+            endpoint_type ep{address_type::from_string("127.0.0.1"), 1234};


ep is unused

wilsonianb · 2017-10-13T16:24:42Z

src/test/rpc/ValidatorRPC_test.cpp

+                    BEAST_EXPECT(js[jss::refresh_interval_min].asUInt() == 5);
+                    BEAST_EXPECT(js[jss::uri] == siteURI);
+                    BEAST_EXPECT(js[jss::last_refresh_status] == "accepted");
+                    // The actual time of the udpate will vary run to run, so


--> update

wilsonianb · 2017-10-13T16:47:56Z

src/ripple/app/misc/impl/ValidatorList.cpp

+    else
+        res[jss::validator_list_expires] = "unknown";
+
+    // Publisher lists


Speaking of redundant information, what do you think about including each publisher list's version, which would always be 1?

wilsonianb · 2017-10-13T16:55:16Z

src/ripple/app/misc/impl/ValidatorList.cpp

+        curr[jss::pubkey_publisher] = strHex(p.first);
+        curr[jss::seq] = static_cast<Json::UInt>(p.second.sequence);
+        curr[jss::available] = p.second.available;
+        curr[jss::expiration] = to_string(p.second.expiration);


For the static list in the config, the entry shows up as:

{ "available" : true, "expiration" : "2136-Feb-07 06:28:15", "list" : [ "n949f75evCHwgyP4fPVgaHqNHxUVN15PsJEZ3B3HnXPcPjcZAoy7", "n9MD5h24qrQqiyBC8aeqqCWvpiBiYQ3jxSr91uiDvmrkyHRdYLUj", "n9L81uNCaPgtUJfaHh89gmdvXKAmSt5Gdsw2g1iPWaPkAHW5Nm4C", "n9KiYM9CgngLvtRCQHZwgC2gjpdaZcCcbt3VboxiNFcKuwFVujzS", "n9LdgEtkmGB9E2h3K4Vp7iGUaKuq23Zr32ehxiU8FWY7xoxbWTSA" ], "pubkey_publisher" : "", "seq" : 0 }

I'm wondering if these should instead be in a third list (static_validator_keys?) outside of publisher_lists, since available, expiration, pubkey_publisher, and seq are all meaningless.

maybe the three lists returned could be something like

local_static_keys

published_lists/dynamic_lists

trusted_keys

I like that distinction, but wasn't sure if the preference is to encourage the use of published_lists over local keys. That being said, its simple to include them.

Maybe the better ordering is:

trusted_keys

local_static_keys

published_lists
?

Since they're keys in a JSON object, I don't think the order is preserved

🤦‍♂️

wilsonianb · 2017-10-13T17:12:30Z

src/ripple/app/misc/impl/ValidatorList.cpp

@@ -479,14 +479,11 @@ ValidatorList::getJson() const
    }

    // Current validator keys
-    Json::Value& jValidatorKeys = (res[jss::validator_keys] = Json::arrayValue);
+    Json::Value& jValidatorKeys =
+        (res[jss::trusted_validator_keys] = Json::arrayValue);
    for (auto const& v : keyListings_)


keyListings_ --> trustedKeys_

wilsonianb · 2017-10-13T17:18:46Z

src/ripple/app/misc/NetworkOPs.cpp

@@ -2148,6 +2148,21 @@ Json::Value NetworkOPsImp::getServerInfo (bool human, bool admin)
    info[jss::validation_quorum] = static_cast<Json::UInt>(
        app_.validators ().quorum ());

+    if (auto when = app_.validators().expires())


I'm wondering if this should be admin-only.
However it does seem to be in a similar category as validation_quorum, which is currently not admin-only.

I could be convinced otherwise, but I like matching validation_quorum, so that if you ever do get stale and validation_quorum goes to "infinity", you would know when it happened.

wilsonianb · 2017-10-18T17:24:49Z

src/ripple/app/misc/NetworkOPs.cpp

+        if (auto when = app_.validators().expires())
+        {
+            if (human)
+                info[jss::validator_list_expires] = to_string(*when);


What do you think about displaying something like "never" or "no expiration" if when equals TimeKeeper::time_point::max()? Same would apply to the validator_lists response

I like "never". I'll update it.

wilsonianb · 2017-10-18T17:42:26Z

src/ripple/rpc/impl/Handler.cpp

@@ -151,6 +151,8 @@ Handler handlerArray[] {
    {   "unl_list",             byRef (&doUnlList),             Role::ADMIN,   NO_CONDITION     },
    {   "validation_create",    byRef (&doValidationCreate),    Role::ADMIN,   NO_CONDITION     },
    {   "validation_seed",      byRef (&doValidationSeed),      Role::ADMIN,   NO_CONDITION     },
+    {   "validator_lists",      byRef (&doValidatorLists),      Role::ADMIN,   NO_CONDITION     },


What do you think about just calling this validators?

Makse sense

Do you think validator_sites should become validator_list_sites to match https://github.com/ripple/rippled/blob/develop/doc/validators-example.txt#L26?

Yeah, that's clearer

bachase · 2017-10-19T15:34:21Z

There were some issue with my use of asio in TrustedPublisherServer, so I went with @wilsonianb's advice and went back to providing the io_service in 661d72f.

wilsonianb · 2017-10-20T20:57:49Z

src/test/app/ValidatorSite_test.cpp

-            ep2, ioService, pubSigningKeys2, manifest2, sequence,
-            expiration.time_since_epoch().count(), version, list2);
+        TrustedPublisherServer server1(
+            ep1,


Should we switch to OS port selection for these servers too?

wilsonianb · 2017-10-20T21:36:03Z

src/ripple/app/misc/impl/ValidatorList.cpp

+    res[jss::validation_quorum] = static_cast<Json::UInt>(quorum());
+
+    if (auto when = expires())
+        res[jss::validator_list_expires] = to_string(*when);


This should also use "never" when when is max()

Uggh, sorry I missed this. Maybe I should just make expires return a string?

Actually, that doesn't work as well with the machine readable response in server_state. I'll just handle it directly.

wilsonianb · 2017-10-20T21:50:00Z

src/ripple/rpc/handlers/Handlers.h

@@ -85,7 +85,8 @@ Json::Value doWalletPropose         (RPC::Context&);
 Json::Value doWalletSeed            (RPC::Context&);
 Json::Value doWalletUnlock          (RPC::Context&);
 Json::Value doWalletVerify          (RPC::Context&);
-
+Json::Value doValidatorLists        (RPC::Context&);


--> doValidators

wilsonianb · 2017-10-20T21:51:13Z

src/ripple/rpc/handlers/Handlers.h

@@ -85,7 +85,8 @@ Json::Value doWalletPropose         (RPC::Context&);
 Json::Value doWalletSeed            (RPC::Context&);
 Json::Value doWalletUnlock          (RPC::Context&);
 Json::Value doWalletVerify          (RPC::Context&);
-
+Json::Value doValidatorLists        (RPC::Context&);
+Json::Value doValidatorSites        (RPC::Context&);


--> doValidatorListSites

wilsonianb · 2017-10-20T22:10:02Z

src/test/rpc/ValidatorRPC_test.cpp

+            auto const jrr = env.rpc("validators")[jss::result];
+            BEAST_EXPECT(
+                jrr[jss::validator_list_expires] ==
+                to_string(NetClock::time_point::max()));


--> "never"

wilsonianb · 2017-10-20T22:21:25Z

src/test/rpc/ValidatorRPC_test.cpp

+                    BEAST_EXPECT(
+                        jp[jss::pubkey_publisher] == strHex(publisherPublic));
+                    BEAST_EXPECT(jp[jss::expiration] ==
+                        to_string(TimeKeeper::time_point{}));


I'm wondering if seq and expiration should either be "unknown" or excluded in this situation

Is there a way to distinguish a list that was previously loaded and is now unavailable versus one that has not been successfully loaded yet?

The expiration would be TimeKeeper::time_point{} in the latter case. (We would never accept a list with that expiration without a time machine.)

bachase · 2017-10-22T17:00:31Z

Rebased on 0.80.0

wilsonianb

Speaking of new ListDispositions, this commit adds same_sequence to distinguish between a fetched list with a previous sequence (and/or expired expiration) from a fetched list with the current sequence, which are both currently treated as stale.
wilsonianb@cfb2ef6
How do you feel about including the change in this PR since it depends on your to_string for ListDisposition?

wilsonianb · 2017-10-23T20:50:19Z

src/ripple/app/misc/impl/ValidatorList.cpp

+    for (auto const& p : publisherLists_)
+    {
+        if (p.second.available &&
+            TimeKeeper::time_point{} < p.second.expiration)


I'm wondering if this should return boost::none if a list has a TimeKeeper::time_point{} expiration (meaning it hasn't been fetched yet).
As is, we have this subset of possible validator_list_expires values:
-unfetched list: unknown
-unfetched list & one or more fetched lists: the timestamp of the soonest expiration
-unfetched list & static validator keys: never

I'm leaning toward always making validator_list_expires to be unknown if any list has yet to be successfully fetched.

Even though the quorum becomes infinite if a list is unavailable, don't you still process/forward validations for whatever trusted nodes are available? If that is the case, I think providing the expiration of the trusted keys you are using is still useful.

But I don't hold that opinion particularly strongly, so if you prefer the above, I will switch.

We'd still have the expiration in each publisher_lists entry for the validators response to tell us when we might stop trusting and forwarding certain validators.
I've been thinking of validator_list_expires as indicating the earliest point at which you might have an incomplete trusted validator list and be unable to reach quorum, but we would need to return something like unknown whenever if we already have an incomplete list.

👍 I'll make the change then.

On a second take, I'm not sure why I was using the available field in this function. That looks to be used to indicate whether a list has been loaded and is unexpired, but if it expires, we don't want to stop reporting its expiry.

Is the better change to just

Return boost::none if any expiration is TimeKeeper::time_point{}

Otherwise, return the earliest expiration.

Good catch. Changing available back to false when the list expires was just added in #2240
Your suggested better change looks correct.

It might be worth adding a test to testExpires and/or testDynamicUNL to check the when/validator_list_expires after a list has expired.
https://github.com/ripple/rippled/blob/cafe18c59279e7de447f25a0e00d0562d6441c7a/src/test/app/ValidatorList_test.cpp#L745-L746

👍 Already working on one in testExpires.

wilsonianb · 2017-10-23T20:57:01Z

src/ripple/app/misc/impl/ValidatorSite.cpp

@@ -267,6 +271,9 @@ ValidatorSite::onSiteFetch(
            JLOG (j_.warn()) <<
                "Unable to parse JSON response from  " <<
                sites_[siteIdx].uri;
+
+            sites_[siteIdx].lastRefreshStatus.emplace(
+                Site::Status{clock_type::now(), ListDisposition::invalid});
        }
    }



We currently don't record a lastRefreshStatus if there was an error fetching the list.
@mtrippled added an else for that case here (should this pr be rebased on that branch as well? 😬)
https://github.com/ripple/rippled/pull/2243/files#diff-746977a6800a792fee7608383bca05deR282
I don't know if we should use ListDisposition::invalid or a new ListDisposition value?

Yes, will add. I think invalid works for now. I don't think a new name would any useful actionable information; clients would likely need to querying the publisher site either way to figure out what is going on.

bachase · 2017-10-23T23:18:20Z

I don't mind adding the same_sequence disposition. I'll rebase to include #2243 and we can always squash #2243, #2240 and this into one commit if this is approved in time. Or I'll continue to rebase, its not that painful.

bachase · 2017-10-24T15:28:50Z

Rebased to include #2243. I went with invalid disposition for the case @mtrippled added in that PR.

wilsonianb

Observation: If a configured trusted publisher key is revoked via its manifest, we simply remove the key and its list.
https://github.com/ripple/rippled/blob/cafe18c59279e7de447f25a0e00d0562d6441c7a/src/ripple/app/misc/impl/ValidatorList.cpp#L279-L283
I don't see a way for us to convey that this happened in the validators rpc response.

wilsonianb · 2017-10-24T16:34:20Z

src/test/app/ValidatorList_test.cpp


+            // Advance past the first list's expiration, but it remains the
+            // earliest expiration
+            env.timeKeeper().set(prep1.expiration + 1s);


I don't think it's necessary, but we could add a call to onConsensusStart here since that is what updates list information (such as available) when a list expires.

wilsonianb · 2017-10-24T17:00:41Z

src/test/rpc/ValidatorRPC_test.cpp

+                    BEAST_EXPECT(js[jss::refresh_interval_min].asUInt() == 5);
+                    BEAST_EXPECT(js[jss::uri] == siteURI);
+                    BEAST_EXPECT(!js.isMember(jss::last_refresh_time));
+                    BEAST_EXPECT(!js.isMember(jss::last_refresh_status));


It looks like these last two checks need to be updated

wilsonianb · 2017-10-24T17:05:47Z

src/ripple/app/misc/impl/ValidatorSite.cpp

@@ -294,6 +294,9 @@ ValidatorSite::onSiteFetch(
    }
    else
    {
+        sites_[siteIdx].lastRefreshStatus.emplace(


I think we want to get the sites_mutex_ lock here

wilsonianb · 2017-10-24T17:08:51Z

src/ripple/app/misc/impl/ValidatorSite.cpp

@@ -294,6 +294,9 @@ ValidatorSite::onSiteFetch(
    }
    else


I just realized we probably also want to set lastRefreshStatus as invalid in the if for this else
https://github.com/ripple/rippled/blob/develop/src/ripple/app/misc/impl/ValidatorSite.cpp#L208-L214

bachase · 2017-10-24T17:36:24Z

I suppose we convey revoking by not having it in the response when the user might expect it. I'm tempted to say that is good enough for now and we can revisit if needed.

wilsonianb

LGTM 👍
Thanks!

wilsonianb · 2017-10-24T20:05:23Z

src/ripple/protocol/JsonFields.h

 JSS ( public_key );                 // out: OverlayImpl, PeerImp, WalletPropose
 JSS ( public_key_hex );             // out: WalletPropose
 JSS ( published_ledger );           // out: NetworkOPs
+JSS ( publisher_lists);             // out: ValidatorList


nit: ( publisher_lists) --> ( publisher_lists )
also for refresh_interval_min and validator_list_expires below

wilsonianb · 2017-10-24T20:15:49Z

src/ripple/rpc/handlers/Validators.cpp

+#include <BeastConfig.h>
+#include <ripple/app/main/Application.h>
+#include <ripple/app/misc/ValidatorList.h>
+#include <ripple/basics/make_lock.h>


I think the make_lock.h include isn't necessary. Ditto for ValidatorListSites.cpp

bachase · 2017-10-24T20:37:53Z

Thanks for the thorough review and suggestions @wilsonianb! I'll fix the remaining nits and squash it down.

wilsonianb · 2017-10-24T20:39:28Z

It looks like this branch has a distinct 0.80.0 version commit, probably due to rebasing on those other branches.

In support of dynamic validator list, this changeset: 1. Adds a new `validator_list_expires` field to `server_info` that indicates when the current validator list will become stale. 2. Adds a new admin only `validator_lists` RPC that returns the current list of known validators and the most recent published validator lists. 3. Adds a new admin only `validator_sites` RPC that returns the list of configured validator publisher sites and when they were most recently queried.

bachase · 2017-11-30T21:52:36Z

Merged as 044dd53

mDuo13 · 2017-12-15T19:33:36Z

For posterity, the two new methods are documented here:
https://ripple.com/build/rippled-apis/#validators
https://ripple.com/build/rippled-apis/#validator-list-sites

bachase assigned mellery451 and wilsonianb Oct 9, 2017

bachase requested review from mellery451 and wilsonianb October 9, 2017 18:46

wilsonianb suggested changes Oct 10, 2017

View reviewed changes

mellery451 suggested changes Oct 10, 2017

View reviewed changes

mellery451 approved these changes Oct 10, 2017

View reviewed changes

wilsonianb reviewed Oct 13, 2017

View reviewed changes

bachase mentioned this pull request Oct 13, 2017

Add validator RPC updates XRPLF/xrpl-dev-portal#278

Closed

wilsonianb reviewed Oct 18, 2017

View reviewed changes

wilsonianb reviewed Oct 20, 2017

View reviewed changes

bachase force-pushed the bc-val-list branch from 661d72f to 5eb3b55 Compare October 22, 2017 17:00

wilsonianb reviewed Oct 23, 2017

View reviewed changes

bachase force-pushed the bc-val-list branch from 832cc78 to 1ff43a3 Compare October 24, 2017 15:26

wilsonianb reviewed Oct 24, 2017

View reviewed changes

wilsonianb approved these changes Oct 24, 2017

View reviewed changes

mtrippled and others added 3 commits October 24, 2017 16:55

Log error conditions when fetching validator list.

d81f1be

Make quorum unreachable if validator list expires (RIPD-1539)

b1a9a5e

bachase force-pushed the bc-val-list branch from f3edb6a to 9b6ce34 Compare October 24, 2017 20:59

wilsonianb mentioned this pull request Nov 22, 2017

Include validator manifests in published list: #2278

Merged

bachase added the Passed Passed code review & PR owner thinks it's ready to merge. Perf sign-off may still be required. label Nov 28, 2017

bachase closed this Nov 30, 2017

Add validator list RPC calls (RIPD-1541) #2242

Add validator list RPC calls (RIPD-1541) #2242

Conversation

bachase commented Oct 9, 2017

bachase commented Oct 9, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

codecov-io commented Oct 10, 2017 • edited Loading

Codecov Report

mellery451 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mellery451 left a comment

Choose a reason for hiding this comment

wilsonianb Oct 13, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bachase commented Oct 19, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bachase commented Oct 22, 2017

wilsonianb left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wilsonianb Oct 24, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bachase commented Oct 23, 2017

bachase commented Oct 24, 2017

wilsonianb left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

codecov-io commented Oct 10, 2017 •

edited

Loading

wilsonianb Oct 13, 2017 •

edited

Loading

wilsonianb left a comment •

edited

Loading

wilsonianb Oct 24, 2017 •

edited

Loading