[bisq-network/bisq] Add UI OfferBook list add/remove checks (#5659)

[Stan]

@ghubstan commented on this pull request.



>                          offer.getId(),
-                        hashOfPayload.getHex());
+                        hashOfPayload == null ? "null" : hashOfPayload.getHex());
+            }
+
+            // The OfferBookListItem with a null or matching payload-hash was not found.
+            // However, when the API's CLI is used to edit and deactivate an offer
+            // in the same command, the edited offer is not re-published (and cannot be
+            // found in local storage).  In this case, we need to remove the deactivated
+            // offer from the list if the local store does not contain an offer with a
+            // matching offerId.
+            if (!isStoredLocally(offer)) {
+                Optional<OfferBookListItem> viewItem = getOfferBookListItem(offer);
+                viewItem.ifPresent((item) -> {
+                    offerBookListItems.remove(item);

>> Why is this needed?

Short explanation is a stale offer with no matching offer (with id) in local protected storage cannot be taken and should be removed from view.

>> Isn't this just to present it nicely to the UI and that's not a problem when running the cli?

The `OfferBookListItem` is a JFX observable used for display in the OfferBook views.  This code block supports the CLI being able to atomically edit and deactivate an offer in the same `editoffer` command, something the UI never does.  When you edit an offer with the UI, you deactivate the offer in the 1st mouse click (pencil button), then re-activate it with the confirm-edit or cancel button clicks -- two separate actions that ensure the temporarily deactivated offer is removed from peers, and the edited (or not) offer is re-published to peers (re-activated).

When the CLI edits _and_ deactivates an offer in the same `editoffer` command, the edited&disabled offer _will not be re-published_ by the API.  On another UI/Peer, the old stale OfferBookListItem would remain (without this code block) in the UI's observable item list because the peer receives on `onRemoved` msg containing the payload-hash of the newly edited offer the peer never received;  there is no matching payload-hash, and `OfferBook.onRemoved(offer, payloadHash)` does not know which item to remove.


-- 
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/5659#discussion_r689686667
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20210816/72569e8d/attachment.htm>