feat: adding block_builder object

[Yael-Starkware]

This change is 

[yair-starkware]

Reviewed 5 of 5 files at r1, all commit messages.
Reviewable status: all files reviewed, 3 unresolved discussions (waiting on @dafnamatsry and @Yael-Starkware)

a discussion (no related file):
You need to run the dump_config executable

---

---

crates/batcher/src/block_builder.rs line 31 at r1 (raw file):

pub struct ExecutionConfig {
    pub chain_info: ChainInfo,
    pub versioned_constants: VersionedConstants,

Get versioned constants by calling get_latest or get instead of from the config

Code quote:

pub versioned_constants: VersionedConstants,

---

crates/batcher/src/block_builder.rs line 85 at r1 (raw file):

}

pub fn get_gas_prices() -> GasPrices {

I don't think it needs to be public

Code quote:

pub

[yair-starkware]

Previously, yair-starkware (Yair) wrote…

You need to run the dump_config executable

nvm it's still not part of the config

[Yael-Starkware]

Reviewable status: 2 of 6 files reviewed, 2 unresolved discussions (waiting on @dafnamatsry and @yair-starkware)

---

crates/batcher/src/block_builder.rs line 31 at r1 (raw file):

Previously, yair-starkware (Yair) wrote…

Get versioned constants by calling get_latest or get instead of from the config

Done.

---

crates/batcher/src/block_builder.rs line 85 at r1 (raw file):

Previously, yair-starkware (Yair) wrote…

I don't think it needs to be public

Done.

[github-actions]

Benchmark movements:
tree_computation_flow performance improved 😺
tree_computation_flow time: [66.461 ms 66.548 ms 66.642 ms]
change: [-9.8368% -6.3500% -3.2339%] (p = 0.00 < 0.05)
Performance has improved.
Found 3 outliers among 100 measurements (3.00%)
2 (2.00%) high mild
1 (1.00%) high severe

[dafnamatsry]

Reviewed 2 of 4 files at r2, all commit messages.
Reviewable status: 4 of 6 files reviewed, 7 unresolved discussions (waiting on @Yael-Starkware and @yair-starkware)

---

crates/batcher/src/block_builder.rs line 16 at r2 (raw file):

pub struct BlockBuilder<S: StateReader> {
    pub executor: TransactionExecutor<S>,

Suggestion:

executor

---

crates/batcher/src/block_builder.rs line 35 at r2 (raw file):

    pub sequencer_address: ContractAddress,
    pub use_kzg_da: bool,
    pub version_constants_overrides: VersionedConstantsOverrides,

Suggestion:

versioned_constants_overrides

---

crates/batcher/src/block_builder.rs line 38 at r2 (raw file):

}

impl<S: StateReader> BlockBuilder<S> {

Please sync with @yair-starkware .
He added a trait of the BlockBuilder and BlockBuilderFactory (In this PR) that defines the API.

2 things to note:

• We need to use the factory pattern to be able to easily test the proposal manager.
• We use channels in order to add txs to the block.

---

crates/batcher/src/block_builder.rs line 42 at r2 (raw file):

        next_block_number: BlockNumber,
        state_reader: S,
        retrospective_block_hash: Option<BlockNumberHashPair>,

Be consistent with the name in the Batcher.

Code quote:

retrospective_block_hash:

---

crates/batcher/src/block_builder.rs line 66 at r2 (raw file):

        let mut state = CachedState::new(state_reader);

        pre_process_block(&mut state, retrospective_block_hash, next_block_number)?;

Does this write to the state? I don't think it should be in the ctor.

[dafnamatsry]

Reviewable status: 4 of 6 files reviewed, 8 unresolved discussions (waiting on @Yael-Starkware and @yair-starkware)

---

crates/batcher/src/block_builder.rs line 39 at r2 (raw file):

impl<S: StateReader> BlockBuilder<S> {
    pub fn new(

Please accept the TransactionExecutor as an argument of the ctor.

[Yael-Starkware]

Reviewable status: 4 of 6 files reviewed, 8 unresolved discussions (waiting on @dafnamatsry and @yair-starkware)

---

crates/batcher/src/block_builder.rs line 16 at r2 (raw file):

pub struct BlockBuilder<S: StateReader> {
    pub executor: TransactionExecutor<S>,

Done.

---

crates/batcher/src/block_builder.rs line 35 at r2 (raw file):

    pub sequencer_address: ContractAddress,
    pub use_kzg_da: bool,
    pub version_constants_overrides: VersionedConstantsOverrides,

Done.

---

crates/batcher/src/block_builder.rs line 38 at r2 (raw file):

Previously, dafnamatsry wrote…

Please sync with @yair-starkware .
He added a trait of the BlockBuilder and BlockBuilderFactory (In this PR) that defines the API.

2 things to note:

• We need to use the factory pattern to be able to easily test the proposal manager.
• We use channels in order to add txs to the block.

I am consistent with the trait, but this is only the ctor, not the trait implementation yet.
The next PR will implement the trait as Yair defined it.
deleting the "add_txs_and_stream" old API from here.

---

crates/batcher/src/block_builder.rs line 39 at r2 (raw file):

Previously, dafnamatsry wrote…

Please accept the TransactionExecutor as an argument of the ctor.

ok, I assume you suggest this in order to make it easier to inject a mock executed for testing and I agree,
This means the block context, state and execute are built outside the ctor, I will keep this logic in an external function.
Done.

---

crates/batcher/src/block_builder.rs line 42 at r2 (raw file):

Previously, dafnamatsry wrote…

Be consistent with the name in the Batcher.

I like this name better because it keeps the block number general in case that someday this won't be 10 blocks ago but some other x blocks ago.
also the type is Hash and BlockNumber pair so the number 10 already appears in the data.

---

crates/batcher/src/block_builder.rs line 66 at r2 (raw file):

Previously, dafnamatsry wrote…

Does this write to the state? I don't think it should be in the ctor.

Yes this function writes to the state directly. I think it makes sense to do it here since it writes to the state directly and does not use the transaction_executor abstraction. (just because that was the intention of the design by the blockifier).
Otherwise, maybe we need to add a function to the transaction_executor that wraps this call. wdty?

[dafnamatsry]

Reviewed 2 of 5 files at r1, 1 of 2 files at r3, all commit messages.
Reviewable status: 5 of 6 files reviewed, 7 unresolved discussions (waiting on @Yael-Starkware and @yair-starkware)

---

crates/batcher/src/block_builder.rs line 42 at r2 (raw file):

Previously, Yael-Starkware (YaelD) wrote…

I like this name better because it keeps the block number general in case that someday this won't be 10 blocks ago but some other x blocks ago.
also the type is Hash and BlockNumber pair so the number 10 already appears in the data.

I agree the other name is not the best, just want to make sure we use the same name across the batcher (Yair already pushed code with a different name).
We can either make the change here or there, not critical to me.

---

crates/batcher/src/block_builder.rs line 66 at r2 (raw file):

Previously, Yael-Starkware (YaelD) wrote…

Yes this function writes to the state directly. I think it makes sense to do it here since it writes to the state directly and does not use the transaction_executor abstraction. (just because that was the intention of the design by the blockifier).
Otherwise, maybe we need to add a function to the transaction_executor that wraps this call. wdty?

I agree it should be in the block_builder, I just don't like that it is implicit (the constructor or this functions are not expected to write anything to the state).
I would put it maybe at the beginning ofbuild_block.

---

crates/batcher/src/block_builder.rs line 44 at r3 (raw file):

    }

    pub fn create_transaction_executor(

Who will calling this function?
I think it would make more sense to put it in the block builder factory.

---

crates/batcher/src/proposals_manager.rs line 81 at r3 (raw file):

pub(crate) struct ProposalsManager {
    config: ProposalsManagerConfig,
    execution_config: ExecutionConfig,

I think this can also be in the BlockBuilderFactory (anything that is about the execution).

Code quote:

execution_config: ExecutionConfig,

[yair-starkware]

Reviewed 2 of 4 files at r2, all commit messages.
Reviewable status: 5 of 6 files reviewed, 5 unresolved discussions (waiting on @dafnamatsry and @Yael-Starkware)

---

crates/batcher/src/block_builder.rs line 31 at r3 (raw file):

pub struct ExecutionConfig {
    pub chain_info: ChainInfo,

Note that you will need to add this to the config pointers like I do in #982

Code quote:

pub chain_info: ChainInfo,

[yair-starkware]

Reviewable status: 5 of 6 files reviewed, 6 unresolved discussions (waiting on @dafnamatsry and @Yael-Starkware)

---

crates/batcher/src/block_builder.rs line 39 at r2 (raw file):

Previously, Yael-Starkware (YaelD) wrote…

ok, I assume you suggest this in order to make it easier to inject a mock executed for testing and I agree,
This means the block context, state and execute are built outside the ctor, I will keep this logic in an external function.
Done.

Why do we need the constructor? And why does it return a result?

---

crates/batcher/src/block_builder.rs line 30 at r3 (raw file):

pub type BlockBuilderResult<T> = Result<T, BlockBuilderError>;

pub struct ExecutionConfig {

Add derives, impl SerializeConfig

---

crates/batcher/src/proposals_manager.rs line 81 at r3 (raw file):

Previously, dafnamatsry wrote…

I think this can also be in the BlockBuilderFactory (anything that is about the execution).

We need to talk about the batcher configuration.
I think all the configs should be nested under a single BatcherConfig struct.
The fact that we use mocks for testing shouldn't make the creation of the batcher more complex from the user's POV.

[Yael-Starkware]

Reviewable status: 5 of 6 files reviewed, 6 unresolved discussions (waiting on @dafnamatsry and @yair-starkware)

---

crates/batcher/src/block_builder.rs line 39 at r2 (raw file):

Previously, yair-starkware (Yair) wrote…

Why do we need the constructor? And why does it return a result?

deleted, done.

---

crates/batcher/src/block_builder.rs line 42 at r2 (raw file):

Previously, dafnamatsry wrote…

I agree the other name is not the best, just want to make sure we use the same name across the batcher (Yair already pushed code with a different name).
We can either make the change here or there, not critical to me.

Done. changed it in batcher_types

---

crates/batcher/src/block_builder.rs line 66 at r2 (raw file):

Previously, dafnamatsry wrote…

I agree it should be in the block_builder, I just don't like that it is implicit (the constructor or this functions are not expected to write anything to the state).
I would put it maybe at the beginning ofbuild_block.

Yoni move it into pre_process_and_create to make it a shared code.

---

crates/batcher/src/block_builder.rs line 30 at r3 (raw file):

Previously, yair-starkware (Yair) wrote…

Add derives, impl SerializeConfig

will add this struct to the config in a separate commit

---

crates/batcher/src/block_builder.rs line 31 at r3 (raw file):

Previously, yair-starkware (Yair) wrote…

Note that you will need to add this to the config pointers like I do in #982

Thanks added a TODO

---

crates/batcher/src/block_builder.rs line 44 at r3 (raw file):

Previously, dafnamatsry wrote…

Who will calling this function?
I think it would make more sense to put it in the block builder factory.

done.
also moved the factory definition into the block_builder file.

---

crates/batcher/src/proposals_manager.rs line 81 at r3 (raw file):

Previously, yair-starkware (Yair) wrote…

We need to talk about the batcher configuration.
I think all the configs should be nested under a single BatcherConfig struct.
The fact that we use mocks for testing shouldn't make the creation of the batcher more complex from the user's POV.

done.

[Yael-Starkware]

Reviewable status: 0 of 14 files reviewed, 6 unresolved discussions (waiting on @dafnamatsry and @yair-starkware)

---

crates/batcher/src/proposals_manager.rs line 81 at r3 (raw file):

Previously, Yael-Starkware (YaelD) wrote…

done.

and sure lets talk.

[yair-starkware]

Reviewed 14 of 14 files at r4, all commit messages.
Reviewable status: all files reviewed, 5 unresolved discussions (waiting on @dafnamatsry)

---

crates/batcher/src/block_builder.rs line 44 at r3 (raw file):

Previously, Yael-Starkware (YaelD) wrote…

done.
also moved the factory definition into the block_builder file.

I don't think we need this function.
For the real flow it will be part of the create_block_builder and for mocking the block builder we don't need to create a transaction executor.

[dafnamatsry]

Reviewed 12 of 14 files at r4, all commit messages.
Reviewable status: all files reviewed, 17 unresolved discussions (waiting on @Yael-Starkware)

---

crates/batcher/src/block_builder.rs line 66 at r2 (raw file):

Previously, Yael-Starkware (YaelD) wrote…

Yoni move it into pre_process_and_create to make it a shared code.

Ok, please rename here also to preprocess_and_create_transaction_executor.

---

crates/batcher/src/block_builder.rs line 33 at r4 (raw file):

use crate::papyrus_state::PapyrusReader;
use crate::proposal_manager::InputTxStream;

Please rearrange the declarations in this file as follows (mainly move trait declaration to be above the implementation, and spme struct definitions to be above their usage):

pub enum BlockBuilderError {}
pub type BlockBuilderResult<T> = Result<T, BlockBuilderError>;
pub struct BlockExecutionArtifacts {}
pub trait BlockBuilderTrait: Send {}
impl BlockBuilderTrait for Box<dyn BlockBuilderTrait> {}

pub struct BlockBuilder {}
impl BlockBuilderTrait for BlockBuilder {}

pub trait BlockBuilderFactoryTrait {}

pub struct ExecutionConfig {}
pub struct BlockBuilderFactory {}
impl BlockBuilderFactory {}
impl BlockBuilderFactoryTrait for BlockBuilderFactory {}

pub trait BlockifierTransactionExecutorTrait: Send {}
impl<S: StateReader + Send + Sync> BlockifierTransactionExecutorTrait for TransactionExecutor<S> {}

---

crates/batcher/src/block_builder.rs line 74 at r4 (raw file):

// TODO (yael 22/9/2024): implement this function for the next milestone
pub fn get_gas_prices() -> GasPrices {

No need to add this function now.
Please use GasPrice::new(...) where needed with a TODO beside.

---

crates/batcher/src/block_builder.rs line 82 at r4 (raw file):

#[derive(Default, Debug, PartialEq)]
pub struct BlockExecutionArtifacts {
    // TODO(yael): what is the best id for mapping? tx_hash or tx_id? depends on the orchestrator

What is the difference?

Code quote:

tx_hash or tx_id?

---

crates/batcher/src/block_builder.rs line 91 at r4 (raw file):

#[async_trait]
impl BlockBuilderTrait for Box<dyn BlockBuilderTrait> {

Why do we need this?

---

crates/batcher/src/block_builder.rs line 105 at r4 (raw file):

#[async_trait]
pub trait BlockBuilderTrait: Send {
    async fn build_block(

Please add documentation.

Code quote:

async fn build_block(

---

crates/batcher/src/block_builder.rs line 115 at r4 (raw file):

#[cfg_attr(test, automock)]
pub trait BlockBuilderFactoryTrait {
    fn create_block_builder(

Please add documentation.

Code quote:

fn create_block_builder(

---

crates/batcher/src/block_builder.rs line 117 at r4 (raw file):

    fn create_block_builder(
        &self,
        next_block_number: BlockNumber,

Suggestion:

height: BlockNumber,

---

crates/batcher/src/block_builder.rs line 129 at r4 (raw file):

impl BlockBuilderFactory {
    pub fn create_transaction_executor(

Suggestion:

fn create_transaction_executor(

---

crates/batcher/src/block_builder.rs line 133 at r4 (raw file):

        next_block_number: BlockNumber,
        retrospective_block_hash: Option<BlockNumberHashPair>,
    ) -> BlockBuilderResult<Box<dyn BlockifierTransactionExecutorTrait>> {

It's the caller decision to hold it in a Box.

Suggestion:

BlockBuilderResult<TransactionExecutor<StorageReader>> 

---

crates/batcher/src/block_builder.rs line 190 at r4 (raw file):

#[cfg_attr(test, automock)]
pub trait BlockifierTransactionExecutorTrait: Send {

Suggestion:

pub trait TransactionExecutorTrait: Send {

---

crates/batcher/src/block_builder.rs line 190 at r4 (raw file):

#[cfg_attr(test, automock)]
pub trait BlockifierTransactionExecutorTrait: Send {

Let's move it to a dedicated file transaction_executor.rs.
This file already has many trait ans struct definitions.

---

crates/batcher/src/block_builder.rs line 191 at r4 (raw file):

#[cfg_attr(test, automock)]
pub trait BlockifierTransactionExecutorTrait: Send {
    fn add_txs_to_block(

Please add documentation for both functions.

Code quote:

fn add_txs_to_block(

---

crates/batcher/src/proposal_manager.rs line 132 at r4 (raw file):

    pub async fn build_block_proposal(
        &mut self,
        block_number: BlockNumber,

The proposal manager holds the active_height already. See https://reviewable.io/reviews/starkware-libs/sequencer/1041#-

Code quote:

block_number: BlockNumber,

[dafnamatsry]

Reviewable status: all files reviewed, 18 unresolved discussions (waiting on @Yael-Starkware)

---

crates/batcher/src/block_builder.rs line 36 at r4 (raw file):

pub struct BlockBuilder {
    _executor: Mutex<Box<dyn BlockifierTransactionExecutorTrait>>,
    _txs_chunk_size: usize,

Suggestion:

_tx_chunk_size

[Yael-Starkware]

Reviewable status: all files reviewed, 18 unresolved discussions (waiting on @dafnamatsry)

---

crates/batcher/src/block_builder.rs line 66 at r2 (raw file):

Previously, dafnamatsry wrote…

Ok, please rename here also to preprocess_and_create_transaction_executor.

Done.

---

crates/batcher/src/block_builder.rs line 44 at r3 (raw file):

Previously, yair-starkware (Yair) wrote…

I don't think we need this function.
For the real flow it will be part of the create_block_builder and for mocking the block builder we don't need to create a transaction executor.

I removed the pub. I think this function adds a nice logic separation. not sure what is the harm in having it.

---

crates/batcher/src/block_builder.rs line 33 at r4 (raw file):

Previously, dafnamatsry wrote…

Please rearrange the declarations in this file as follows (mainly move trait declaration to be above the implementation, and spme struct definitions to be above their usage):

pub enum BlockBuilderError {}
pub type BlockBuilderResult<T> = Result<T, BlockBuilderError>;
pub struct BlockExecutionArtifacts {}
pub trait BlockBuilderTrait: Send {}
impl BlockBuilderTrait for Box<dyn BlockBuilderTrait> {}

pub struct BlockBuilder {}
impl BlockBuilderTrait for BlockBuilder {}

pub trait BlockBuilderFactoryTrait {}

pub struct ExecutionConfig {}
pub struct BlockBuilderFactory {}
impl BlockBuilderFactory {}
impl BlockBuilderFactoryTrait for BlockBuilderFactory {}

pub trait BlockifierTransactionExecutorTrait: Send {}
impl<S: StateReader + Send + Sync> BlockifierTransactionExecutorTrait for TransactionExecutor<S> {}

will do in a seperate PR after we push these two since I don't want to get too many conflicts.

---

crates/batcher/src/block_builder.rs line 36 at r4 (raw file):

pub struct BlockBuilder {
    _executor: Mutex<Box<dyn BlockifierTransactionExecutorTrait>>,
    _txs_chunk_size: usize,

Done.

---

crates/batcher/src/block_builder.rs line 74 at r4 (raw file):

Previously, dafnamatsry wrote…

No need to add this function now.
Please use GasPrice::new(...) where needed with a TODO beside.

Done.

---

crates/batcher/src/block_builder.rs line 82 at r4 (raw file):

Previously, dafnamatsry wrote…

What is the difference?

this comment was deleted in the following PR. deleting here as well.
done.

---

crates/batcher/src/block_builder.rs line 91 at r4 (raw file):

Previously, dafnamatsry wrote…

Why do we need this?

deleted

---

crates/batcher/src/block_builder.rs line 105 at r4 (raw file):

Previously, dafnamatsry wrote…

Please add documentation.

Done.

---

crates/batcher/src/block_builder.rs line 115 at r4 (raw file):

Previously, dafnamatsry wrote…

Please add documentation.

Done.

---

crates/batcher/src/block_builder.rs line 117 at r4 (raw file):

    fn create_block_builder(
        &self,
        next_block_number: BlockNumber,

Done.

---

crates/batcher/src/block_builder.rs line 129 at r4 (raw file):

impl BlockBuilderFactory {
    pub fn create_transaction_executor(

Done.

---

crates/batcher/src/block_builder.rs line 133 at r4 (raw file):

Previously, dafnamatsry wrote…

It's the caller decision to hold it in a Box.

the compiler is saying that
the size for values of type (dyn block_builder::BlockBuilderTrait + 'static) cannot be known at compilation time
the trait std::marker::Sized is not implemented for (dyn block_builder::BlockBuilderTrait + 'static)

---

crates/batcher/src/block_builder.rs line 190 at r4 (raw file):

#[cfg_attr(test, automock)]
pub trait BlockifierTransactionExecutorTrait: Send {

Done.

---

crates/batcher/src/block_builder.rs line 190 at r4 (raw file):

Previously, dafnamatsry wrote…

Let's move it to a dedicated file transaction_executor.rs.
This file already has many trait ans struct definitions.

sure, will l do in the seperate PR where I rearrange this file.

---

crates/batcher/src/block_builder.rs line 191 at r4 (raw file):

Previously, dafnamatsry wrote…

Please add documentation for both functions.

Done.

---

crates/batcher/src/proposal_manager.rs line 132 at r4 (raw file):

Previously, dafnamatsry wrote…

The proposal manager holds the active_height already. See https://reviewable.io/reviews/starkware-libs/sequencer/1041#-

not sure how to solve this right now, added a a todo

[dafnamatsry]

Reviewed 1 of 14 files at r4, 4 of 4 files at r5, all commit messages.
Reviewable status: all files reviewed, 4 unresolved discussions (waiting on @Yael-Starkware)

---

crates/batcher/src/block_builder.rs line 133 at r4 (raw file):

Previously, Yael-Starkware (YaelD) wrote…

the compiler is saying that
the size for values of type (dyn block_builder::BlockBuilderTrait + 'static) cannot be known at compilation time
the trait std::marker::Sized is not implemented for (dyn block_builder::BlockBuilderTrait + 'static)

Note I suggested to return a non generic type BlockBuilderResult<TransactionExecutor<StorageReader>>.

---

crates/batcher/src/block_builder.rs line 81 at r5 (raw file):

}

/// The BlockBuilderTrait is responsible for building a new block from ransactions provided in

Suggestion:

transactions

---

crates/batcher/src/proposal_manager.rs line 132 at r4 (raw file):

Previously, Yael-Starkware (YaelD) wrote…

not sure how to solve this right now, added a a todo

You can put a temp value when calling create_block_builder with a todo.
This way the API and tests will stay the same.

[Yael-Starkware]

Reviewable status: 11 of 14 files reviewed, 4 unresolved discussions (waiting on @dafnamatsry and @yair-starkware)

---

crates/batcher/src/block_builder.rs line 133 at r4 (raw file):

Previously, dafnamatsry wrote…

Note I suggested to return a non generic type BlockBuilderResult<TransactionExecutor<StorageReader>>.

Done.

---

crates/batcher/src/block_builder.rs line 81 at r5 (raw file):

}

/// The BlockBuilderTrait is responsible for building a new block from ransactions provided in

Done.

---

crates/batcher/src/proposal_manager.rs line 132 at r4 (raw file):

Previously, dafnamatsry wrote…

You can put a temp value when calling create_block_builder with a todo.
This way the API and tests will stay the same.

Done.

[dafnamatsry]

Reviewed 3 of 3 files at r6, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @Yael-Starkware)

[dafnamatsry]

Reviewed 8 of 8 files at r7, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @Yael-Starkware)

[dafnamatsry]

Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @Yael-Starkware)

[codecov]

Codecov Report

Attention: Patch coverage is 2.18579% with 179 lines in your changes missing coverage. Please review.

Project coverage is 63.85%. Comparing base (b0cfe82) to head (771ecc4).
Report is 268 commits behind head on main.

Files with missing lines	Patch %	Lines
crates/batcher/src/papyrus_state.rs	0.00%	89 Missing ⚠️
crates/batcher/src/block_builder.rs	1.33%	74 Missing ⚠️
crates/batcher/src/batcher.rs	0.00%	15 Missing ⚠️
crates/blockifier/src/blockifier/block.rs	0.00%	1 Missing ⚠️

❗ There is a different number of reports uploaded between BASE (b0cfe82) and HEAD (771ecc4). Click for more details.

HEAD has 2 uploads less than BASE

Flag	BASE (b0cfe82)	HEAD (771ecc4)
	3	1

Additional details and impacted files

@@             Coverage Diff             @@
##             main     #745       +/-   ##
===========================================
- Coverage   74.18%   63.85%   -10.33%     
===========================================
  Files         359      117      -242     
  Lines       36240    13096    -23144     
  Branches    36240    13096    -23144     
===========================================
- Hits        26886     8363    -18523     
+ Misses       7220     4349     -2871     
+ Partials     2134      384     -1750     

Flag	Coverage Δ
	?

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.