Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Fix] Fix handling of empty recipts int fast sync #702

Merged
merged 3 commits into from
Sep 29, 2020

Conversation

KonradStaniec
Copy link
Contributor

@KonradStaniec KonradStaniec commented Sep 28, 2020

Description

Two fixes:

  • FastSync, while receiving empty receipts reduce thrown exception - new UnsupportedOperationException("empty.reduceLeft") which killed sync. In general it means that our error hanlding in actor is less than stellar, but for now just handle empty case.
  • Sometimes our tests timeout in EthashUtilsSpec, try to fix it by rewriting recursive function in tail recursive manner and by changing number generation logic

@KonradStaniec KonradStaniec force-pushed the fix/fix-empty-receipts-handling branch from a071ad4 to aa71fbe Compare September 28, 2020 09:41
syncState = syncState.enqueueReceipts(remainingReceipts)
}
if (receipts.isEmpty) {
val reason = s"got empty receipts for known hashes: ${requestedHashes.map(h => Hex.toHexString(h.toArray[Byte]))}"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very minor: we have helper method ByteStringUtils.hash2String

sendReceipts(newBlocks.map(_.hash), Seq(), peer1)

// Peer will be blacklisted for empty response, so wait he is blacklisted
Thread.sleep(6.second.toMillis)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why 6 seconds? Maybe we could tweak some test params? This test will take a lot of time

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or use mock clock maybe?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I reduced sleeps in case of blacklist (and blacklist config).

I agree @kapke that mock clock would be perfect, but at current state sync state is almost black box and there is so much timing/scheduling happening inside that those whole testsuit would require little refactor and i would prefer to create separate task to do it

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea. Maybe, for now, we could tag time-consuming tests like that and skip it by default for development purposes (and run on CI only). Now the whole test suite takes more than 30m. WDYT?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I created task for both of this possible improvements - https://jira.iohk.io/browse/ETCM-147.

But on my machine whole testsuite takes 6min so it is not that much, I am not sure why tests on CI takes that long.

@@ -2,18 +2,20 @@ package io.iohk.ethereum.consensus.ethash

import akka.util.ByteString
import io.iohk.ethereum.crypto.kec256
import org.scalacheck.Arbitrary
import org.scalacheck.{Gen}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very minor: strange format of import

Copy link
Contributor

@mmrozek mmrozek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Minor comment only

@KonradStaniec KonradStaniec merged commit 7abdf78 into develop Sep 29, 2020
@KonradStaniec KonradStaniec deleted the fix/fix-empty-receipts-handling branch September 29, 2020 09:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants