Skip to content
This repository has been archived by the owner on Feb 5, 2025. It is now read-only.

Add builder transaction status API #236

Merged
merged 44 commits into from
Nov 26, 2024
Merged

Add builder transaction status API #236

merged 44 commits into from
Nov 26, 2024

Conversation

dailinsubjam
Copy link
Contributor

@dailinsubjam dailinsubjam commented Nov 6, 2024

Closes #175

This PR:

  • Add API to claim transaction status.
  • Set transaction status under different cases.
  • Add test in legacy builder to check we have correct status recorded for each transaction.
  • Add pruning by setting target number of transactions we want to save with status.

This PR does not:

  • Implement or add test for marketplace builder yet.
  • Add fine-grained pruning yet, like minimum retention or target retention, which will be done next.
  • Add tests to check transaction submitted through public mempool event stream, it only checks txn submitted from hotshot for now.
  • Add tests to check other error types besides "TransactionTooBig".
  • Mark sequenced and record leaf height offset when transaction is sequenced, as it's not a high priority.

Key places to review:

@dailinsubjam dailinsubjam marked this pull request as draft November 6, 2024 17:47
@coveralls
Copy link

coveralls commented Nov 6, 2024

Pull Request Test Coverage Report for Build 12005235276

Details

  • 274 of 318 (86.16%) changed or added relevant lines in 5 files are covered.
  • 3 unchanged lines in 1 file lost coverage.
  • Overall coverage decreased (-0.07%) to 89.629%

Changes Missing Coverage Covered Lines Changed/Added Lines %
crates/marketplace/src/service.rs 0 5 0.0%
crates/legacy/src/service.rs 267 306 87.25%
Files with Coverage Reduction New Missed Lines %
crates/legacy/src/service.rs 3 92.82%
Totals Coverage Status
Change from base Build 11854071961: -0.07%
Covered Lines: 6888
Relevant Lines: 7685

💛 - Coveralls

@dailinsubjam dailinsubjam marked this pull request as ready for review November 8, 2024 06:23
crates/legacy/src/builder_state.rs Outdated Show resolved Hide resolved
crates/legacy/src/builder_state.rs Outdated Show resolved Hide resolved
crates/legacy/src/service.rs Outdated Show resolved Hide resolved
crates/legacy/src/service.rs Show resolved Hide resolved
crates/legacy/src/service.rs Outdated Show resolved Hide resolved
crates/marketplace/src/service.rs Outdated Show resolved Hide resolved
crates/legacy/src/service.rs Outdated Show resolved Hide resolved
crates/legacy/src/service.rs Outdated Show resolved Hide resolved
crates/marketplace/src/service.rs Outdated Show resolved Hide resolved
crates/legacy/src/service.rs Show resolved Hide resolved
crates/legacy/src/service.rs Outdated Show resolved Hide resolved
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);
Copy link
Contributor

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.

Copy link
Contributor Author

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?

Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Updated in 5b3f1b7.

@@ -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>>>,
Copy link
Contributor

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?

Copy link
Member

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. 😃

Copy link
Contributor Author

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.

Copy link
Contributor

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Updated in ea9e606.

Copy link
Member

@shenkeyao shenkeyao left a 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.

@@ -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>>>,
Copy link
Member

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. 😃

crates/legacy/src/service.rs Outdated Show resolved Hide resolved
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 replace unwrap() calls in this file with better handling unless they are in tests?

Copy link
Contributor Author

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.

Copy link
Member

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 Show resolved Hide resolved
crates/legacy/src/service.rs Outdated Show resolved Hide resolved
@@ -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>>>,
Copy link
Contributor

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

&self,
_txn_hash: Commitment<<Types as NodeType>::Transaction>,
) -> Result<TransactionStatus, BuildError> {
todo!("Implement this function");
Copy link
Contributor

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

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);
Copy link
Contributor

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.

crates/legacy/src/service.rs Outdated Show resolved Hide resolved
Copy link
Member

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.

@dailinsubjam dailinsubjam merged commit 62b5c43 into main Nov 26, 2024
7 of 8 checks passed
@dailinsubjam dailinsubjam deleted the sishan/tx_status_api branch November 26, 2024 00:54
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Cartesi Issues] - Builder transaction status API
4 participants