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

SYS-3773 Bug fix to handle bad transaction hashes and various improvements #342

Merged
merged 5 commits into from
Dec 18, 2023

Conversation

nahuseyoum
Copy link
Contributor

@nahuseyoum nahuseyoum commented Dec 16, 2023

Proposed changes

This PR fixes a bug where ethereum events gets stuck processing invalid transaction hashes. It also adds a new event to signal retries and automatically sets expiry period during a forkless upgrade.

Type of change/Merge

🚨What type of change is this PR?

Put an x in the boxes that apply

  • Release
    • Increase versions
    • Baseline tests passed
    • Release type:
      • Major release
      • Minor release
      • Patch release

Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR.

  • You describe the purpose of the PR, e.g.:
    • What does it do?
    • Highlight what important points reviewers should know about;
    • Indicates if there is something left for follow-up PRs.
  • Documentation updated
  • Business logic tested successfully
  • Verify First, Write Last: In Substrate development, it is important that you always ensure preconditions are met and return errors at the beginning. After these checks have completed, then you may begin the function's computation.

Further comments

@nahuseyoum nahuseyoum changed the title Bug fix to handle bad transaction hashes and various improvements SYS-3773 Bug fix to handle bad transaction hashes and various improvements Dec 18, 2023
@nahuseyoum nahuseyoum merged commit 941dc1d into main Dec 18, 2023
10 checks passed
@nahuseyoum nahuseyoum deleted the nahu-v4Fixes branch December 18, 2023 10:18
assert_eq!((next_tx_id as u64).encode(), new_transaction_id_bytes);
assert_eq!(expiry, 7200);
Copy link
Contributor

Choose a reason for hiding this comment

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

Why do we do this assert here? This forces the expiry to be a fixed constant, and in that case, why does it exist as a storage item?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is on state migration only

@@ -105,6 +105,12 @@ pub fn set_up_active_tx<T: Config>(req: SendRequestData) -> Result<(), Error<T>>
}

pub fn replay_send_request<T: Config>(mut tx: ActiveTransactionData<T>) -> Result<(), Error<T>> {
Copy link
Contributor

Choose a reason for hiding this comment

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

I see this is called from finalize_state, and that in turn is called from add_corroboration. But I don't see any limit to how many times we retry, or why we want to retry if we know the transaction has already failed.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If the sender is a malicious author, we retry until we find an honest author

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.

5 participants