Improve capabilities updates and transport syncing order #2838
Conversation
When depositing to UDC, after the tx just got mined, it emits a udcDeposit.success. So far, it was being emitted with the value it just got from a new effectiveBalance call, which may be outdated because the tx didn't get confirmed yet. Instead, we now calculate the actual "final" effectiveBalance to be used there since we know it from previous balance.
Codecov Report
@@ Coverage Diff @@
## master #2838 +/- ##
==========================================
- Coverage 93.68% 93.58% -0.11%
==========================================
Files 110 110
Lines 6038 6030 -8
Branches 1093 1093
==========================================
- Hits 5657 5643 -14
- Misses 326 332 +6
Partials 55 55
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
ensures there's some time after raiden start before updating capabilities on matrix for the first time; also, matrix gets started only after raiden is synced, to avoid receiving messages while we're not ready yet.
Do this only after we're synced and matrix is started. To force this update, we quickly appear offline then back online, although syncing isn't interrupted.
andrevmatos
force-pushed
the
improv/caps_updates
branch
from
9ca8b7f to
a775107
Compare
|
Now I just approved... 😆 |
|
Works like charm. 😊 |
Good eyes. Yes, it is, mainly because it'd be hard to know when balance changed got confirmed on the monitoring epic, because there there's no txHash. Also, there's nowhere depending on this being confirmed, it's just something we depend (so we can enable receiving or not), so there's nothing to get out of sync if this is still unconfirmed. |
|
What happens in case the transaction gets reorged? Would this reset the receiving capability again? |
In case of reorgs, the balance would be updated as soon as the reorg got detected and the capability would immediately reflect this change, if needed. Nonetheless, I just pushed a small change to ensure we only set |
Fixes #2831
Short description
We implemented the workaround to quickly toggle our transport status between
offlineand backonlineto trigger PFS to be informed of our new capabilities. Additionally, some needed fixes went into transport code handling capabilities updates:udcDepositEpicwon't push outdatedbalancewhen mining the transaction, which did cause a wrongudcDeposit.successupdate and respectiveReceive=0capability to be set for a short period of time. Also, transport now is prepared before but started only whensynced, to only then appear asonlineand start receiving transport events. Finally, some previous presence workaround tries were cleaned up, since they don't make sense anymore with PFS-based presence mechanism.Definition of Done
Steps to manually test the change (dApp)
monitoringReward)curl -vL https://pfs-goerli-with-fee.services-dev.raiden.network/api/v1/address/<address>/metadata