Add Action Lock

[mateeullahmalik]

Summary

Add thread-safe mutex locking to the action module to prevent race conditions when submitting concurrent transactions to the blockchain mempool.

Problem

The action module was experiencing race conditions when multiple goroutines attempted to execute transactions concurrently (e.g., multiple RequestAction or
FinalizeCascadeAction calls). This caused errors during transaction creation, signing, and broadcasting to the mempool, potentially leading to:

• Nonce conflicts (multiple transactions using the same sequence number)
• Transaction signing failures due to concurrent key access
• Inconsistent transaction state during mempool submission
• Potential data races in the transaction helper's internal state

Solution

This PR introduces a sync.Mutex to the action module struct, ensuring that transaction execution is serialized. The sync.Mutex is a Go synchronization
primitive that provides mutual exclusion - only one goroutine can hold the lock at a time, forcing all others to wait until the lock is released.

Changes

• Import sync package: Add sync for mutex support
• Add mutex field: Include sync.Mutex in the module struct
• Protect RequestAction: Lock/unlock mutex around transaction execution to prevent concurrent action requests from interfering
• Protect FinalizeCascadeAction: Lock/unlock mutex around transaction execution to prevent concurrent finalization calls from interfering

Technical Details

Each transaction goes through several steps:

1. Creating the message with the correct creator/signer
2. Signing the transaction with the keyring
3. Broadcasting to the blockchain mempool

Without synchronization, concurrent calls could:

• Retrieve the same account sequence number (nonce)
• Sign transactions with conflicting nonces
• Cause mempool rejection or unpredictable transaction ordering

[akobrin1]

I think we don't need lock for RequestAction

[Copilot]

Pull Request Overview

This PR introduces thread-safe mutex locking to the action module to prevent race conditions during concurrent transaction submissions. The primary concern is preventing nonce conflicts and transaction signing failures when multiple goroutines execute transactions simultaneously.

Key Changes:

• Added sync.Mutex to the action module struct for mutual exclusion
• Protected RequestAction and FinalizeCascadeAction methods with mutex locks around transaction execution
• Lock is acquired after parameter validation and held during the entire transaction flow (account info retrieval, message creation, signing, and broadcasting)

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[roomote-v0]

Rooviewer   See task on Roo Cloud

Review completed: changes look good. The mutex addition correctly serializes transaction operations to prevent race conditions.

• Review action module transaction locking
• Verify tx helper and action module interaction
• Confirm no additional changes required for this PR

Previous reviews

• 2f2e159: Review #1

_{Mention @roomote in a comment to request specific changes to this pull request or fix all unresolved issues.}

[roomote-v0]

Rooviewer   See task on Roo Cloud

Review completed: the introduction of sync.Mutex correctly addresses the race conditions described.

• Minor optimization: Avoid redundant keyring lookup in SimulateFinalizeCascadeAction

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[roomote-v0]

Inside SimulateFinalizeCascadeAction, we are calling m.txHelper.GetAccountInfo(ctx) and then m.txHelper.GetCreatorAddress().

Note that GetAccountInfo internally calls GetCreatorAddress to look up the account. By calling GetCreatorAddress again explicitly on the next line (to pass creator to createFinalizeActionMessage), we are duplicating the keyring lookup overhead inside the lock.

Since this is running sequentially under a lock, it might be worth optimizing to fetch the address once and reuse it, or just accepting the overhead if it's negligible. Just a small observation.

Resolved on Discord