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(block-production): fix bouncer, error reporting, debug messages #271

Open
wants to merge 17 commits into
base: main
Choose a base branch
from

Conversation

cchudant
Copy link
Member

This is on antiyro's current legacy class hash branch but i can rebase it on main if we want it merged before

Pull Request type

Please add the labels corresponding to the type of changes your PR introduces:

  • Bugfix

What is the current behavior?

Bouncer fraction is wrong

What is the new behavior?

  • Correct bouncer fraction
  • Better error reporting around mempool and block production
  • Better debug messages and info messages

Does this introduce a breaking change?

No

Copy link
Collaborator

@Trantorian1 Trantorian1 left a comment

Choose a reason for hiding this comment

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

⚠️ You have an incorectly guarded division by 0, please fix this

See comments below for more details

@@ -25,7 +25,7 @@ jobs:

- uses: software-mansion/setup-scarb@v1
with:
scarb-version: "2.7.0"
scarb-version: "2.8.2"
Copy link
Collaborator

Choose a reason for hiding this comment

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

Doesn't this pose an issue with devnet as scarb 2.8.2 is not yet compatible with starknet? You can check with @apoorvsadana, I remember he had an issue related to this.

.map_err(|e| BlockImportError::ComputeClassHash { class_hash: legacy.class_hash, error: e })?;
if class_hash != legacy.class_hash {
// TODO: For now we skip the exceptions for the legacy class hash mismatch
log::debug!("Class hash mismatch: got {:#x}, expected {:#x}", class_hash, legacy.class_hash,);
Copy link
Collaborator

Choose a reason for hiding this comment

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

Ehhhh, is this a good idea?

column_sizes: registry
.register(IntGaugeVec::new(Opts::new("column_sizes", "Sizes of RocksDB columns"), &["column"])?)?,
})
}

/// Returns the total storage size
Copy link
Collaborator

Choose a reason for hiding this comment

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

Do we currently have the metrics behind a compilation flag? I'm just wondering as it could make sense if the resulting performance hit is noticeable. Might not be needed though, I saw we check the db only once every 200 blocks. This is more of a general observation and request for feedback.

// - use u128 here because the multiplication would overflow
// - div by zero: current_pending_tick has been checked for 0 above
let reduced_cap =
|v: usize| (v as u128 * current_pending_tick as u128 / n_pending_ticks_per_block as u128) as usize;
Copy link
Collaborator

Choose a reason for hiding this comment

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

n_pending_ticks_per_block should be checked instead of current_pending_tick!


fn parse_legacy_entrypoint(entrypoint: &LegacyContractEntryPoint, pre_0_11_0: bool) -> RawLegacyEntryPoint {
RawLegacyEntryPoint {
// This doesn't really matter as it doesn't affect class hashes. We simply try to guess as
Copy link
Collaborator

Choose a reason for hiding this comment

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

How so?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Status: In progress
Development

Successfully merging this pull request may close these issues.

5 participants