🪣 Reinforce Transaction Related Flows on the Client

[timolegros]

Describe the bug

We have 2 flows (that I know of) on the client that are extremely brittle because they require both a transaction and an API request to complete successfully in the same sequence to result in a 'success' state:

• Namespace creation:
  • Reserve Namespace txn lost in Stake enablement flow #8831
  • Re-org handling
• Contest deployment

These flows are brittle because if the transaction succeeds but the user exits the browser or loses their network connection before the API request can complete, the user is left in an inconsistent state. For example, if a user creates a namespace with a txn but the subsequent API request fails, the namespace they created is now reserved and they must start again with a completely new namespace. The reverse is also problematic, if the transaction and API request for creating a namespace initially succeed but the transaction is removed from the chain during a reorganization, the database will still store the namespace info (address/name) but it will no longer exist on-chain (this scenario is rare but arguably worse from a user perspective).

We need to build flows that are resilient to such issues. Possible strategies include:

• Require a certain number of confirmations before a transaction is considered final
• Separate the transaction and API request into separate steps e.g.:
  • Create the namespace with a transaction
  • "Attach" to community in the next step
    • If this step fails we can prompt the user to retry completing their namespace integration by querying the chain directly for the associated namespace
• Use Alchemy-reinforced transactions

Outcomes

• Research and reinforce all transaction-related flows on the client
• Define a pattern for future transaction flows that are inherently resistant to transaction or API failures.

Additional context

Related to:

• Chain Reorganization Handling #8764
• [SPIKE] SubQuery Integration #8790