Bugs on v0.6.0 full list

[Reckless-Satoshi]

Describe the bugs This is a list of bug fixes needed on the federated app v0.6.0 (https://github.com/RoboSats/robosats/tree/the-federation-layer-v0.6.0) for functionality parity with v0.5.3 (i.e., a list of things that do not work as expected in v0.6.0 but used to work on v0.5.3).

• [ ] Landing on /create will show coordinators not sorted by the federationLottery() . The v0.5.4 (and prior) loading bar at the top of the maker form that was shown while loadingLimits===true is also not shown, however, you can tell limits are not yet loaded because advancedOptions does not work. All of these three issues might have a common cause. Possibly adding a loading spinner next to the Coordinator aliases on the dropdown is useful (rather than hide them while the /api/info response has not yet arrived).
• [ ] There seems to be an issue very rare where sometimes, after locking the bond, the ErrorBoundary is triggered and a Borked app page is show. Seems to be related to an Order object where .price is not found (null not expected).
• [ ] The avatar generator webworker/wasm might stop working on a browser tab refresh.
• [ ] There seems to be some mishap with PGP keys across different robots on the same garage. To find this issue showing up: 1) Create a robot and create an order. 2) Open a new browser tab. 3)Create another robot, take the previous order. 4) Follow the trade until chat. 5) message each other in the chat. You will see one of the two robots (or both) cannot validate the peer's signatures on the chat messages. In fact, the peer is signing the messages with the wrong private key it seems. Weird!
• [ ] Robots can now be generated much faster than the time it takes for the response of coordinators to know if there are active orders. Users might think there is no active / past orders if they are not patient enough. We should add an indeterminate progress bar cycling while there are still pending coordinator responses after generating a new robot.
• [ ] ProfileDialog loading animation does not work. Similar issue to order book loading bar. There should be an indicator of waiting for /api/robot requests, same as when generating a robot, everytime the profile is opened.
• [ ] It seems a second robot in the Garage cannot create an order. "You are already a maker of an active order". That is a backend response, meaning, the header of that request was sent with the wrong robot identity (the other robot's identity). This and the previous bulletpoint probably have a common cause. Maybe the slot keeps the info of the previous robot (pgp keys, base91 token, etc).
• [ ] Sometimes the Order tab is not clickable even when the Robot has an active order.
• [ ] Sometimes, renewing an order (i.e., creating a new order with same params as one that expired) will not show you the order just created (it will not trigger a reload, probably because of a very large delay between requests). However leaving the Order tab and coming back will work.
• [ ] Aggregated summary stats behaves weird. The aggregation is broken. Sometimes is stuck at 0 values. It does not re-trigger on mainnet/testnet switch click. Does not trigger a updateCoordinators() when the ExchangeSummary dialog is opened (as it used to be on v0.5.4). Last 24h average premium is sometimes NaN%.
• [ ] Deleting a custom payment method in the MakerForm crashes the client.
• [x] Order book reload does not display loading bar showing N out of M coordinator's book loaded. Possibly not listening to changes of book.loading of coordinators.
• [x] fixed Amount range values missing on OrderDetails as PrimaryText on orders when clicking on them from the OrderBook.
• [x] fixed There seems to be too many calls to federation.fetchRobot(). This function is called every time page changes (tab navigation) somewhere in the app (could not find where) or as a second effect reaction of something.
• [x] partially fixed Order current order fetching and re-render does not work 100% of the time. Edit: partially fixed by implementing a context-wide currentOrder and currentOrderId https://github.com/RoboSats/robosats/pull/922/commits/ed9dd3599f4fc8a9a8b70c1e21678d531091b6aa This commit fixed the reliability issue, but did not solve the issue of navigating in/out of order on the order book. Possibly clicking on the order book triggers more timer fetching loops.
• [x] fixed https://github.com/RoboSats/robosats/pull/1085 Garage saves might lose robots (research needed). On garage delete and refresh the last robot is still shown ( the garage slots are deleted from localStorage and instantly re-created).
• [x] fixed OrderDetails, some variables are not there sometimes. For example, the dropdown of Amount/Currency might show "undefined" as currency.
• [x] fixed Tab switch from Order to another bounces back. The navigate() use throughout the app does not trigger a page change as it used to, meaning an explicit setPage() is now needed on all actions that take the user to another tab. Best solution involves making navigate() trigger automatic page changes.

// L24 /src/components/Dialogs/Profile 
  useEffect(() => {
    setLoading(!garage.getSlot()?.hashId);
  }, [robotUpdatedAt]);

hashId is not a valid way to check if a robot is loading. Each robot has its own loading flag ( ...getSlot().robots[shortAlias].loading ) so a check for n out of m loading === false is needed.

Other things to improve that are not bugs but are a priority under a multi-coordinator set up:

• [ ] Add to /api/info new variables max_swap_allowed, swaps_disabled. Display these 2 and also maxOrderSize in the CoordinatorSummary dialog.
• [ ] Strong forbid of robot reuse! Forbid order creation if your robot has an activeOrder or a lastOrder with any coordinator.

[KoalaSat]

hashId is not a valid way to check if a robot is loading. Each robot has its own loading flag ( ...getSlot().robots[shortAlias].loading ) so a check for n out of m loading === false is needed.

But the only thing the user requires for the robot to start using using it is to have the hashid and the avatar, do we really to wait an answer for all coordinators?

[Reckless-Satoshi]

But the only thing the user requires for the robot to start using using it is to have the hashid and the avatar, do we really to wait an answer for all coordinators?

No, we do not "wait" to be able to use the robot. But we show a visual cue that the request to the coordinators (N of M) is still ongoing in case the user opens the ProfileDialog. If the response from the coordinators is not yet there, we show the loading progress on top of the Dialog. This is important given that there might be Active or Past orders for that robot and, on a quick look, the user might find "nothing" and be unaware that the information from the coordinator did not arrive yet.

[KoalaSat]

There seems to be an issue very rare where sometimes, after locking the bond, the ErrorBoundary is triggered and a Borked app page is show. Seems to be related to an Order object where .price is not found (null not expected).

I tried to lock multiple bonds but couldn't reproduce it, do you have logs?

It seems a second robot in the Garage cannot create an order. "You are already a maker of an active order". That is a backend response, meaning, the header of that request was sent with the wrong robot identity (the other robot's identity). This and the previous bulletpoint probably have a common cause. Maybe the slot keeps the info of the previous robot (pgp keys, base91 token, etc).

Same situation, it's likely this got fixed with my last PR, can you try?

[KoalaSat]

Sometimes the Order tab is not clickable even when the Robot has an active order.

Sometimes, renewing an order (i.e., creating a new order with same params as one that expired) will not show you the order just created (it will not trigger a reload, probably because of a very large delay between requests). However leaving the Order tab and coming back will work.

These 2 should have been also fixed with the magic PR

[KoalaSat]

Deleting a custom payment method in the MakerForm crashes the client.

I can't reproduce this one

[Reckless-Satoshi]

v0.6.0 is now merged. The remaining items in this list might still be a problem but are hard to reproduce as of now. We will close this issue and create dedicated issues for each bug from now own.