-
Notifications
You must be signed in to change notification settings - Fork 3
Conversation
Pull Request Test Coverage Report for Build 12005235276Details
💛 - Coveralls |
crates/legacy/src/service.rs
Outdated
let old_status = write_guard.get(&txn_hash); | ||
match old_status { | ||
Some(TransactionStatus::Rejected { reason }) => { | ||
tracing::error!("Changing the status of a rejected transaction to status {:?} is not allowed! The reason it is rejected is {:?}", txn_status, reason); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We will run into most of this cases quite frequently during normal operation, I'd downgrade this to debug.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is that? Is this due to a rejected txn could be submitted twice?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I'd expect cases where we get duplicates either directly or through hotshot gossiping not to be very rare.
It doesn't indicate that something's wrong with the builder, so I wouldn't categorize this as an error.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see, then I'd better also not return BuildError in such cases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated in 5b3f1b7.
crates/legacy/src/service.rs
Outdated
@@ -180,6 +183,9 @@ pub struct GlobalState<Types: NodeType> { | |||
|
|||
pub block_size_limits: BlockSizeLimits, | |||
|
|||
// A mapping from transaction hash to its status | |||
pub tx_status: Arc<RwLock<lru::LruCache<Commitment<Types::Transaction>, TransactionStatus>>>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason we want to wrap this in an Arc
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this for multi-thread updates? I'll let Sishan confirm/explain though. 😃
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, I wrapped it in an Arc just in case we need to use spawn with a clone of GlobalState in the future, even though we don’t have such a case yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're wrapping the whole GlobalState in an Arc already in ProxyGlobalState, so that seems superfluous
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated in ea9e606.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mostly lock-related comments.
crates/legacy/src/service.rs
Outdated
@@ -180,6 +183,9 @@ pub struct GlobalState<Types: NodeType> { | |||
|
|||
pub block_size_limits: BlockSizeLimits, | |||
|
|||
// A mapping from transaction hash to its status | |||
pub tx_status: Arc<RwLock<lru::LruCache<Commitment<Types::Transaction>, TransactionStatus>>>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this for multi-thread updates? I'll let Sishan confirm/explain though. 😃
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we replace unwrap()
calls in this file with better handling unless they are in tests?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed to .await?
so that any errors will be propagated up the call stack. 490d452.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Commented at the place still with an unwrap
.
crates/legacy/src/service.rs
Outdated
@@ -180,6 +183,9 @@ pub struct GlobalState<Types: NodeType> { | |||
|
|||
pub block_size_limits: BlockSizeLimits, | |||
|
|||
// A mapping from transaction hash to its status | |||
pub tx_status: Arc<RwLock<lru::LruCache<Commitment<Types::Transaction>, TransactionStatus>>>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're wrapping the whole GlobalState in an Arc already in ProxyGlobalState, so that seems superfluous
crates/marketplace/src/service.rs
Outdated
&self, | ||
_txn_hash: Commitment<<Types as NodeType>::Transaction>, | ||
) -> Result<TransactionStatus, BuildError> { | ||
todo!("Implement this function"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we return an Error here instead of panicking? I know we don't have this deployed yet, but I'd rather not panic in non-testing code anyways
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
crates/legacy/src/service.rs
Outdated
let old_status = write_guard.get(&txn_hash); | ||
match old_status { | ||
Some(TransactionStatus::Rejected { reason }) => { | ||
tracing::error!("Changing the status of a rejected transaction to status {:?} is not allowed! The reason it is rejected is {:?}", txn_status, reason); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I'd expect cases where we get duplicates either directly or through hotshot gossiping not to be very rare.
It doesn't indicate that something's wrong with the builder, so I wouldn't categorize this as an error.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Commented at the place still with an unwrap
.
Closes #175
This PR:
This PR does not:
sequenced
and recordleaf height
offset
when transaction is sequenced, as it's not a high priority.Key places to review: