[#9927] Fast blocks sync after being offline #9942
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Pull Request Checklist
|
rasom
changed the title
Jenkins BuildsClick to see older builds (12)
|
|
@rasom could you describe what was changed and how it fixed the issue? looks like it works better for me now, I tried on a recover account and sent funds and the transaction was updated shortly after etherescan shows the update which was not the case before. To verify I also went back to RC4 and sent a transaction after starting the app (killed for a while, no background) and it still shows as pending when etherscan already confirmed 5 blocks) |
|
@yenda
|
|
can you add the explanation in the commit message? |
rasom
force-pushed
the
fast-block-sync-after-delay
branch
from
81f2424
to
fef9276
Compare
flexsurfer
approved these changes
Jan 29, 2020
|
@yenda yes it is |
rasom
force-pushed
the
fast-block-sync-after-delay
branch
2 times, most recently
from
0d6d2fb
to
4396991
Compare
|
@yenda @flexsurfer ready for review and testing, message is added |
flexsurfer
approved these changes
Jan 30, 2020
yenda
approved these changes
Jan 30, 2020
|
when did we stop supporting reorg of blocks and have this delay instead? |
|
@yenda we never stopped to support reorgs, what do you mean? |
|
@yenda as far as I understand the idea of that safetyDepth thing was rather to minimise the occurrences of reorgs in the app to avoid "flickering" state there, that's the best I can suggest (it seems that I have no one to ask about details). But we still handle reorgs if necessary. |
|
Works great for me on Android 8, iOS 13: sent tokens and ETH from 1-1 chat / Wallet appear in Wallet history according to the confirmations I compared in Etherscan. No delay, (well maybe +- 1 block which is absolutely fine). |
Front end changes:
As there is no guarantee that `newblock` event will be dispatched
consequently (e.g. if there was a delay after block#1 the next event
might be dispatched for a block#2000, no guarantee that block#2 will be
the next one), `newTransactions` field was added with a map of accounts
to the number of new transactions received to this block. In result if
there are new transactions we request them all of db instead of fetching
them on for the block specified in `newblock` event, as it was done
previously.
Back end changes:
- In order to avoid handling of the reorganized blocks we use an offset
from the latest known block when start listening to new blocks. Before
this commit the offset was 15 blocks for all networks. This offset is
too big for mainnet and causes noticeable delay of marking a transfer as
confirmed in Status (comparing to etherscan). So it was changed to be 5
blocks on mainnet and is still 15 blocks on other networks.
- Also before this commit all new blocks were handled one by one with
network specific interval (10s for mainnet), which means that in case of
lost internet connection or application suspension (happens on iOS)
receiving of new blocks would be paused and then resumed with the same
"speed" - 1 blocks per 10s. In case if that pause is big enough the
application would never catch up with the latest block in the network,
and this also causes the state of transfers to be delayed in the
application. In this commit in case if there was more than 40s delay
after receiving of the previous block the whole history in range between
the previous received block and ("latest"-reorgeSafetyDepth) block is
checked at once and app catches up with a recent state of the chain.
rasom
force-pushed
the
fast-block-sync-after-delay
branch
from
4396991
to
b41df2f
Compare
rasom
added a commit
to status-im/status-go
that referenced
this pull request
Jan 31, 2020
rasom
added a commit
to status-im/status-go
that referenced
this pull request
Jan 31, 2020
Storing absolute path for different configs breaks compatibility on iOS as app's dir is changed after upgrade. The solution is to store relative paths and to concatenate it with `backend.rootDataDir`. The only exception is `LogFile` as it is stored outside `backend.rootDataDir` on Android. `LogDir` config was added to allow adding of custom dir for log file. Configs concerned: `DataDir` `LogDir` `LogFile` `KeystoreDir` `BackupDisabledDataDir`
rasom
added a commit
that referenced
this pull request
Jan 31, 2020
rasom
added a commit
to status-im/status-go
that referenced
this pull request
Feb 3, 2020
Storing absolute path for different configs breaks compatibility on iOS as app's dir is changed after upgrade. The solution is to store relative paths and to concatenate it with `backend.rootDataDir`. The only exception is `LogFile` as it is stored outside `backend.rootDataDir` on Android. `LogDir` config was added to allow adding of custom dir for log file. Configs concerned: `DataDir` `LogDir` `LogFile` `KeystoreDir` `BackupDisabledDataDir`
rasom
added a commit
to status-im/status-go
that referenced
this pull request
Feb 3, 2020
Storing absolute path for different configs breaks compatibility on iOS as app's dir is changed after upgrade. The solution is to store relative paths and to concatenate it with `backend.rootDataDir`. The only exception is `LogFile` as it is stored outside `backend.rootDataDir` on Android. `LogDir` config was added to allow adding of custom dir for log file. Configs concerned: `DataDir` `LogDir` `LogFile` `KeystoreDir` `BackupDisabledDataDir`
rasom
added a commit
that referenced
this pull request
Feb 3, 2020
Storing absolute path for different configs breaks compatibility on iOS as app's dir is changed after upgrade. The solution is to store relative paths and to concatenate it with `backend.rootDataDir`. The only exception is `LogFile` as it is stored outside `backend.rootDataDir` on Android. `LogDir` config was added to allow adding of custom dir for log file. Configs concerned: `DataDir` `LogDir` `LogFile` `KeystoreDir` `BackupDisabledDataDir`
flexsurfer
pushed a commit
that referenced
this pull request
Feb 3, 2020
Storing absolute path for different configs breaks compatibility on iOS as app's dir is changed after upgrade. The solution is to store relative paths and to concatenate it with `backend.rootDataDir`. The only exception is `LogFile` as it is stored outside `backend.rootDataDir` on Android. `LogDir` config was added to allow adding of custom dir for log file. Configs concerned: `DataDir` `LogDir` `LogFile` `KeystoreDir` `BackupDisabledDataDir`
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
fix #9927
Front end changes:
As there is no guarantee that
newblockevent will be dispatchedconsequently (e.g. if there was a delay after block#1 the next event
might be dispatched for a block#2000, no guarantee that block#2 will be
the next one),
newTransactionsfield was added with a map of accountsto the number of new transactions received to this block. In result if
there are new transactions we request them all of db instead of fetching
them on for the block specified in
newblockevent, as it was donepreviously.
Back end changes:
from the latest known block when start listening to new blocks. Before
this commit the offset was 15 blocks for all networks. This offset is
too big for mainnet and causes noticeable delay of marking a transfer as
confirmed in Status (comparing to etherscan). So it was changed to be 5
blocks on mainnet and is still 15 blocks on other networks.
network specific interval (10s for mainnet), which means that in case of
lost internet connection or application suspension (happens on iOS)
receiving of new blocks would be paused and then resumed with the same
"speed" - 1 blocks per 10s. In case if that pause is big enough the
application would never catch up with the latest block in the network,
and this also causes the state of transfers to be delayed in the
application. In this commit in case if there was more than 40s delay
after receiving of the previous block the whole history in range between
the previous received block and ("latest"-reorgeSafetyDepth) block is
checked at once and app catches up with a recent state of the chain.
status: ready