Light-client: dApp: Direct transfer fails with "The Requested target doesn't receive transfers"

[taleldayekh]

Steps to Reproduce

1. Make a direct transfer

Expected Result

• A direct transfer happens without invoking the pfs.

Actual Result

• Pfs needs to be selected and when continuing a "Requested target doesn't receive transfers" error appears.

Additional Infos (Optional)

Logs:
raiden_0xAdF4209810C442f5772c27F2Fd25Dc56Dcc0615c_2021-06-22T12_49_53.265Z.log.zip

[andrevmatos]

The need for a PFS comes from the fact that the request for a direct transfer fails, so it may be that a mediated one would be possible (if the cause was e.g. lack of capacity in the direct channel).
The Requested target doesn't receive transfers happens because target doesn't have the minimum UDC deposit to pay for request monitoring for that channel, which we raised from 5 to 80 SVT.
This "direct error" of course isn't _workaround-able_ by selecting a mediated route, but we don't differentiate between both cases right now, and just try the mediated one in case the direct one failed. We could optimise this, but since this is a quite edgy case, I wouldn't say it's a priority.
To fix this, simply ensure you've more than 80 SVT deposited in UDC in the target. Please, close if the issue is explained.

[palango]

To fix this, simply ensure you've more than 80 SVT deposited in UDC in the target.

They had 160 SVT deposited.

[weilbith]

To fix this, simply ensure you've more than 80 SVT deposited in UDC in the target.

They had 160 SVT deposited.

Yes. I observed the same. I had deposited thousands of tokens in the contract and reloaded all nodes a couple of times. At some point one of them started to work.
From the code it should be just this simple check Andre mentioned. But something else seem to "block"/"shadow" it.

[andrevmatos]

Ok, it seems the issue is that the PFS isn't updating its view our our capabilities when it changes. Workaround for now is for the node which just deposited to UDC to go offline, stay like that for at least 30s, and then come back online. I'm also preparing a PR to debounce capability updates when deposit is confirming, which may improve this a little, but until PFS doesn't properly update this field, the timing in capability changes will bring us this kind of problems.
https://github.com/raiden-network/light-client/issues/2831

[weilbith]

Is it worth to implement such a workaround in the client? Shouldn't we push to fix the PFS?

[andrevmatos]

The fix necessarily needs to go on PFS side, from what I could see, this can't be fixed in our side. But while debugging/reproducing it, I did see some things that can/should be improved on our side which can reduce the number of this kind of events on the server, and I think this should be implemented.

[andrevmatos]

Ok, I got a weird workaround (better known in Brasil as _gambiarra_) for this, which is: once our capability changes, we can quickly appear offline, then immediately as online again, and this will trigger a PFS presence update. Notice we don't actually need to go offline, we'd still keep syncing as before and no event would be lost, and since PFSs don't have a mechanism to push these presence updates to clients (it's polling only), this would affect only them.

Theoretically there could be a very small time window here in which we'd appear as offline, which could then make incoming (mediated or received) transfers fail if a partner requested our presence right at the few milliseconds PFS thought we were offline, but since capabilities updates at runtime are quite uncommon, and namely the only condition which may change at then is exactly Receive being turned on or off, then appearing offline for this very short timeframe doesn't matter (since you'd already not be able to receive/mediate either before or after such update), and this would optimise for the most common case: user depositing to UDC in order to receive and request monitoring for a transfer, and getting confused by still not being able to.

Do you guys think this is worth it? I already got it implemented and tested, but I'm not sure if such _workaround_ is something we'd like to push for.

[weilbith]

Sounds good to me. As you said this is most-likely only happening during runtime if the user deposits to UDC and reaches the critical amount. This means he wasn't able to receive transfers before (by default configuration). So he actually can't receive a transfer where this could cause issues. I think this is totally fine. In my opinion such a distributed network must just be able to handle offline users better anyway. So I would go with it. 👍🏾