Skip to content

Conversation

@attila0x2A
Copy link
Contributor

There is a race condition in which when block is being processed incoming receipts would be stored as pending but may never be processed. If block was already processed we would try applying it and would process receipts before detecting that it's already applied.

There is a race condition in which when block is being processed
incoming receipts would be stored as pending but may never be processed.
If block was already processed we would try applying it and would
process receipts before detecting that it's already applied.
@attila0x2A attila0x2A requested a review from pugachAG December 12, 2025 12:18
@attila0x2A attila0x2A requested a review from a team as a code owner December 12, 2025 12:18
@attila0x2A attila0x2A changed the title fix(spice): fix possible memory leak in executor pending receipts fix(spice): fix memory leak in executor pending receipts Dec 12, 2025
@attila0x2A attila0x2A requested a review from darioush December 12, 2025 16:00
@attila0x2A
Copy link
Contributor Author

@darioush @pugachAG friendly ping

Copy link
Contributor

@darioush darioush left a comment

Choose a reason for hiding this comment

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

approving to unblock

simulate_single_outgoing_message(&mut actors, &message);
}
record_endorsements(&mut actors, &first_block);
let second_block = produce_block(&mut actors, &first_block);
Copy link
Contributor

Choose a reason for hiding this comment

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

What's the role of second_block in this test?

Comment on lines +213 to +217
// Some additional receipts can arrive after we have already started executing the block. (For
// example when we are tracking several shards for which we aren't chunk producer or we get
// receipts from different peers with different commitments in which case data distributor
// wouldn't know which is right.) In this case we want to make sure we process pending
// receipts to make sure don't leak memory by storing unverified receipts indefinitely.
Copy link
Contributor

Choose a reason for hiding this comment

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

It seems to me that we could have receipts arrive after block in the case where the chunk producer is also requesting the missing data (i.e., receive receipts from pull & push path).

I didn't understand the part about tracking several shards.

Also to check my understanding, receiving data with different commitments, would not currently be possible since the distributor_actor has waiting_on_data and recently_decoded_data, but in the future it will be possible?

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.

3 participants