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

Return error from TxPool level if the BlobId is known #2067

Merged
merged 6 commits into from
Aug 9, 2024

Conversation

xgreenx
Copy link
Collaborator

@xgreenx xgreenx commented Aug 9, 2024

Return error from TxPool level if the BlobId is known. Currently, we only return it from the block producer level.

Checklist

  • New behavior is reflected in tests

Before requesting review

  • I have reviewed the code myself

@xgreenx xgreenx requested a review from a team August 9, 2024 13:59
@xgreenx xgreenx self-assigned this Aug 9, 2024
messages: HashMap::new(),
max_depth,
utxo_validation,
}
}

/// find all dependent Transactions that are inside txpool.
/// Does not check db. They can be sorted by gasPrice to get order of dependency
pub(crate) fn find_dependent(
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

It is not used anywhere, so I removed it=)

}

if let Some(state) = self.blobs.get(blob_id) {
if state.tip >= tx.tip() {
Copy link
Member

Choose a reason for hiding this comment

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

This doesn't seem like a "collision" error, but we are returning NotInsertedCollisionBlobId

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

If new transaction that deploys the same Blob has lower tip, it is a collision. We can't have two transactions that deploy the same Blob

Copy link
Member

Choose a reason for hiding this comment

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

Sure. It's a collision if it's < as well though. What we're really doing here is choosing which tx we like more. To the end user the collision error is helpful, I guess, and not inaccurate. NotInsertedCollisionBlobIdTipLowerThanOtherTx would be more encompassing.

I guess I'm having a hard time parsing this function. It would help if it was a little more declarative.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

It would be nice to change all other places as well with a better name. But it is not part of this PR and will be addressed during the refactoring of the TxPool=) You can check https://github.com/FuelLabs/fuel-core/tree/feature/txpool-v2 it already uses better names.

@@ -268,7 +222,34 @@ impl Dependency {
let mut max_depth = 0;
let mut db_coins: HashMap<UtxoId, CoinState> = HashMap::new();
let mut db_contracts: HashMap<ContractId, ContractState> = HashMap::new();
let mut db_blobs: HashMap<BlobId, BlobState> = HashMap::new();
Copy link
Member

Choose a reason for hiding this comment

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

This is missing from the docstring.

nit: it shouldn't be a docstring and should just be a comment since it's private.

@@ -268,7 +222,34 @@ impl Dependency {
let mut max_depth = 0;
let mut db_coins: HashMap<UtxoId, CoinState> = HashMap::new();
let mut db_contracts: HashMap<ContractId, ContractState> = HashMap::new();
let mut db_blobs: HashMap<BlobId, BlobState> = HashMap::new();
Copy link
Member

Choose a reason for hiding this comment

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

Also, does this need to be a HashMap? Couldn't it just be an Option<(BlobId, BlobState)>? We shouldn't ever insert more than one.

Copy link
Member

Choose a reason for hiding this comment

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

Not as relevant considering comment below.

@@ -475,7 +463,7 @@ impl Dependency {
where
DB: TxPoolDb,
{
let (max_depth, db_coins, db_contracts, db_messages, collided) =
let (max_depth, db_coins, db_contracts, db_blobs, db_messages, collided) =
self.check_for_collision(txs, db, tx)?;
Copy link
Member

Choose a reason for hiding this comment

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

Do you know why check_for_collision is taking a dyn TxPoolDb instead of a generic DB like db here?

Copy link
Collaborator Author

@xgreenx xgreenx Aug 9, 2024

Choose a reason for hiding this comment

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

I don't know=) But let's leave it for the refactoring of the TxPool

}

if let Some(state) = self.blobs.get(blob_id) {
if state.tip >= tx.tip() {
Copy link
Member

Choose a reason for hiding this comment

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

Sure. It's a collision if it's < as well though. What we're really doing here is choosing which tx we like more. To the end user the collision error is helpful, I guess, and not inaccurate. NotInsertedCollisionBlobIdTipLowerThanOtherTx would be more encompassing.

I guess I'm having a hard time parsing this function. It would help if it was a little more declarative.

@@ -461,7 +442,14 @@ impl Dependency {
// collision of other outputs is not possible.
}

Ok((max_depth, db_coins, db_contracts, db_messages, collided))
Ok((
Copy link
Member

@MitchTurner MitchTurner Aug 9, 2024

Choose a reason for hiding this comment

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

The name is check_for_collision. I'd expect a function named that to return Result<()> or maybe Result<Vec<TxId>>, but it's returning a bunch of HashMaps as well. Ideally we don't have single function responsible for multiple things, but at the very least we could name the function something more accurate.

I'd prefer to move the db extension logic to separate functions.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I just did it the same way it had worked before. I don't see a point in refactoring the code that will be removed soon during the refactoring of the TxPool.

@@ -1421,3 +1355,139 @@ async fn predicate_that_returns_false_is_invalid() {
"unexpected error: {err}",
)
}

#[tokio::test]
async fn insert_blob_works() {
Copy link
Member

@MitchTurner MitchTurner Aug 9, 2024

Choose a reason for hiding this comment

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

Suggested change
async fn insert_blob_works() {
async fn insert_single__blob_tx_works() {

let result = txpool.insert_single(tx);

// Then
let _ = result.expect("Should insert blob");
Copy link
Member

Choose a reason for hiding this comment

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

Can we check that the tx is included rather than looking for an Ok?

}

#[tokio::test]
async fn insert_the_same_blob_fails_in_txpool_level() {
Copy link
Member

@MitchTurner MitchTurner Aug 9, 2024

Choose a reason for hiding this comment

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

Suggested change
async fn insert_the_same_blob_fails_in_txpool_level() {
async fn insert_single__blob_tx_fails_if_blob_already_inserted_and_lower_tip() {

}

#[tokio::test]
async fn insert_the_same_blob_works_with_higher_tip() {
Copy link
Member

@MitchTurner MitchTurner Aug 9, 2024

Choose a reason for hiding this comment

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

Suggested change
async fn insert_the_same_blob_works_with_higher_tip() {
async fn insert_single__blob_tx_succeeds_if_blob_already_inserted_but_higher_tip() {

}

#[tokio::test]
async fn insert_the_same_blob_fails_in_database_level() {
Copy link
Member

@MitchTurner MitchTurner Aug 9, 2024

Choose a reason for hiding this comment

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

Suggested change
async fn insert_the_same_blob_fails_in_database_level() {
async fn insert_single__blob_tx_fails_if_blob_already_exists_in_database() {

@xgreenx xgreenx requested review from MitchTurner and a team August 9, 2024 20:53
@MitchTurner MitchTurner merged commit 279b123 into master Aug 9, 2024
34 checks passed
@MitchTurner MitchTurner deleted the feature/return-error-for-the-same-blob-id branch August 9, 2024 21:54
@MitchTurner MitchTurner mentioned this pull request Aug 9, 2024
xgreenx pushed a commit that referenced this pull request Aug 10, 2024
### Added
- [2061](#2061): Allow
querying filled transaction body from the status.

### Changed
- [2067](#2067): Return error
from TxPool level if the `BlobId` is known.
- [2064](#2064): Allow gas
price metadata values to be overridden with config

### Fixes
- [2060](#2060): Use
`min-gas-price` as a starting point if `start-gas-price` is zero.
- [2059](#2059): Remove unwrap
that is breaking backwards compatibility
- [2063](#2063): Don't use
historical view during dry run.

## What's Changed
* Bugfix: Remove unwrap in Consensus Param conversion by @MitchTurner in
#2059
* Don't use historical view during dry run by @xgreenx in
#2063
* Weekly `cargo update` by @github-actions in
#2050
* Allow gas price metadata values to be overridden with config by
@MitchTurner in #2064
* Use `min-gas-price` as a starting point if `start-gas-price` is zero
by @xgreenx in #2060
* Allow querying transaction from the status by @xgreenx in
#2061
* Return error from TxPool level if the `BlobId` is known by @xgreenx in
#2067


**Full Changelog**:
v0.32.0...v0.32.1
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.

2 participants