2023-04-25T19:04:20.848Z DEBUG net net/relay.go:74 received invalid taker-specific claim request from peer=12D3KooWKNweo3pR2BSXGpNs5rDa7bG2MoueMhFZ5Hw4uXaTdJ6c offerID=0xabdd2c94ccda33d8a86a1bdcbd5f229eeea29f477c55a2d44ac5291a391b5d13 swap-found=false
Scenario: xmrmaker uses xmrtaker to do counterparty-specific relay (ie xmrtaker has relaying set to false). xmrtaker restarts their node at some point during the swap, before xmrmaker tries to send a claim relay request. then, once the xmrmaker sends the claim relay request to the xmrtaker, the xmrtaker doesn't accept its request because it doesn't think (on the network level) that it has an ongoing swap with them, because the net.Host.swaps map isn't re-propagated on restart. The log above is what the xmrtaker sees.
Easy solution is to move the counterparty-check to backend.HandleRelayClaimRequest() and use the swapManager to check 1. we are doing that swap currently 2. we are the taker and 3. the peer ID matches
Scenario: xmrmaker uses xmrtaker to do counterparty-specific relay (ie xmrtaker has relaying set to false). xmrtaker restarts their node at some point during the swap, before xmrmaker tries to send a claim relay request. then, once the xmrmaker sends the claim relay request to the xmrtaker, the xmrtaker doesn't accept its request because it doesn't think (on the network level) that it has an ongoing swap with them, because the
net.Host.swapsmap isn't re-propagated on restart. The log above is what the xmrtaker sees.Easy solution is to move the counterparty-check to
backend.HandleRelayClaimRequest()and use theswapManagerto check 1. we are doing that swap currently 2. we are the taker and 3. the peer ID matches