[bisq-network/bisq] Refactor capabilities (#2552)

[Florian Reimair]

freimair commented on this pull request.



> @@ -176,7 +176,7 @@ public void readPersisted() {
         PeerList persistedPeerList = storage.initAndGetPersistedWithFileName("PeerList", 1000);
         if (persistedPeerList != null) {
             long peersWithNoCapabilitiesSet = persistedPeerList.getList().stream()
-                    .filter(e -> e.getCapabilities().hasCapabilities())
+                    .filter(e -> e.getCapabilities().isEmpty())

asdf

> @@ -176,7 +176,7 @@ public void readPersisted() {
         PeerList persistedPeerList = storage.initAndGetPersistedWithFileName("PeerList", 1000);
         if (persistedPeerList != null) {
             long peersWithNoCapabilitiesSet = persistedPeerList.getList().stream()
-                    .filter(e -> e.getCapabilities().hasCapabilities())
+                    .filter(e -> e.getCapabilities().isEmpty())

This is a bug which has been introduced with the previous refactoring.

The goal is a list of peers which have no capabilities assigned. This list is counted and then reported either as `log.warn` (in case more than hardcoded 100 persisted peers have no capabilities assigned) or a `log.info`. Currently, however, the code counts peers which have capabilities (`hasCapabilities`) assigned. So no breaking bug that shows itself easily.

This change restores the functionality as intended originally by leaving only peers with empty capability sets in the list.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/bisq/pull/2552#discussion_r266586536
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20190318/5258a323/attachment-0001.html>