Added Interrupted status to transaction entity

[GabrielMartinezRodriguez]

Linked Issues

• closes https://linear.app/happychain/issue/HAPPY-365/txm-handle-cases-where-the-nonce-moved-past-an-intent-but-all-our

Description

This PR addresses the problem we were experiencing in production, where there was a nonce that had been used, but we did not have the corresponding attempt recorded in our system. This was causing infinite retries or cancellations if the transaction had a deadline.

Now, we have implemented a new status, Interrupted, where transactions meeting this criteria are moved. The user can decide to include the transaction again by sending it through the originator function.

• Include all relevant context (but no need to repeat the issue's content).
• Draw attention to new, noteworthy & unintuitive elements.

Toggle Checklist

Checklist

Basics

• B1. I have applied the proper label & proper branch name (e.g. norswap/build-system-caching).
• B2. This PR is not so big that it should be split & addresses only one concern.
• B3. The PR targets the lowest branch it can (ideally master).

Reminder: PR review guidelines

Correctness

• C1. Builds and passes tests.
• C2. The code is properly parameterized & compatible with different environments (e.g. local,
  testnet, mainnet, standalone wallet, ...).
• C3. I have manually tested my changes & connected features.

< INDICATE BROWSER, DEMO APP & OTHER ENV DETAILS USED FOR TESTING HERE >

< INDICATE TESTED SCENARIOS (USER INTERFACE INTERACTION, CODE FLOWS) HERE >

• C4. I have performed a thorough self-review of my code after submitting the PR,
  and have updated the code & comments accordingly.

Architecture & Documentation

• D1. I made it easy to reason locally about the code, by (1) using proper abstraction boundaries,
  (2) commenting these boundaries correctly, (3) adding inline comments for context when needed.
• D2. All public-facing APIs & meaningful (non-local) internal APIs are properly documented in code
  comments.
• D3. If appropriate, the general architecture of the code is documented in a code comment or
  in a Markdown document.
• D4. An appropriate Changeset has been generated (and committed) for changes that touch npm published packages (currently pacakges/core and packages/react), see here for more info.

[cloudflare-workers-and-pages]

Deploying happychain with    Cloudflare Pages

Latest commit:	caa054f
Status:	✅  Deploy successful!
Preview URL:	https://3c8eb51d.happychain.pages.dev
Branch Preview URL:	https://gabriel-transaction-reorder.happychain.pages.dev

View logs

[GabrielMartinezRodriguez]

• Added Interrupted status to transaction entity #434 : 2 dependent PRs (#435 , #458 ) 👈 (View in Graphite)
• Deploy randomness service #416 : 1 other dependent PR (#441 )
• Add config contract #404
• Randomness service: Improve performance and reliability #372
• Add transaction submission failure hook and error handling #366
• Increase default RPC timeout to 2000ms #365
• Add configurable HTTP polling interval for block monitoring #362
• Force initialization before using the TXM #361
• Script to monitor randomness service #325
• Script to easily launch the randomness service locally #324
• Submit drand numbers #318
• Random oracle contracts #307
• Only prune finalized randomness entries #305
• Add NewBlock hook #304
• Refactors the randomness service to be able to process pending commitments  #303
• Add SQLite persistence to randomness service #300
• Txm no longer receives Viem objects #298 : 1 other dependent PR (#299 )
• Add flush mechanism #289 : 1 other dependent PR (#297 )
• Allow run multiple txm simultaneously within the same service #285
• Added docs for txm #272
• Mutex in tx monitor #264
• Purge transactions #232
• Txm hooks #229
• Use kysely instead of mikro-orm #250
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

[linear]

HAPPY-365 TXM: Handle cases where the nonce moved past an intent but all our attemps are not included

Probably add new status, something like TRANSACTION_REORDER.

The tx can then re-enqueue it from an originator if need be.

The downside is we can have the tx "cut in line" — but because we already assigned nonces and probably submitted the other txs in the queue, this would require implementing nonce renumbering, which is bound to be extremely messy and complex.

This should never happen anyway — in theory it only happens if the submitter key is used concurrently somewhere else.