Bug/1621 tx dropped silently when ctq full

[PropzSaladaz]

Description

This PR fixes a transaction queue issue where a transaction could be silently dropped when the current transaction queue (CTQ) was full - see #1621

Previously, queue insertion happened mostly through the CTQ path. If CTQ exceeded its limits, the queue could drop a transaction internally to recover capacity while still returning success to the caller. That meant the client/RPC layer had no reliable signal that the submitted transaction was not actually accepted.

The new behavior makes queue admission explicit:

• First, the transaction is checked for CTQ eligibility.
• If it can go into CTQ and CTQ has capacity, it is inserted there.
• If CTQ is full, the queue now tries to insert the transaction into FTQ when future-queue support is enabled.
• If FTQ is disabled or FTQ is also full, the transaction is rejected with QueueIsFull.
• The client converts that result into a TransactionQueueIsFull error, so RPC callers are informed instead of seeing a silent drop.

At a logical level, CTQ remains the preferred queue for executable/contiguous transactions, while FTQ acts as the fallback for valid transactions that are either future nonces OR cannot currently fit into CTQ. If neither queue can accept the transaction, the failure is now explicit and observable.

Fixes #1621

[github-actions]

SUGGESTIONS BEFORE MERGE:

1. Build custom container here: https://github.com/skalenetwork/skaled/actions?query=workflow%3A%22Custom+Docker+and+Binary%22
2. Test it here: https://github.com/skalenetwork/skale-ci-integration_tests/actions?query=workflow%3A%22Skaled+Nightly+Tests%22
3. Edit VERSION file appropriately to your changes!
   See https://skalelabs.atlassian.net/wiki/spaces/SKALE/pages/2444951553/Branching+instructions

[Copilot]

Pull request overview

This PR updates SKALED’s transaction queue admission logic to avoid “successful” imports that later result in silent transaction loss when the current transaction queue (CTQ) is at capacity. It makes queue insertion outcomes explicit, propagates QueueIsFull up to the client/RPC layer, and expands unit tests around CTQ/FTQ behavior.

Changes:

• Refactors TransactionQueue::import() to require caller-provided stateNonce and an explicit allowFutureQueue flag, and adds ImportResult::QueueIsFull.
• Updates Client to pass the committed sender nonce and convert QueueIsFull into a new TransactionQueueIsFull exception; maps that exception to an RPC error message.
• Updates/extends unit tests to validate CTQ/FTQ admission and full-queue rejection behavior.

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
libethereum/TransactionQueue.h	Changes import API to require allowFutureQueue + stateNonce; adds new internal helpers.
libethereum/TransactionQueue.cpp	Implements explicit CTQ/FTQ insertion paths and QueueIsFull handling; adjusts drop/import semantics.
libethcore/Common.h	Adds ImportResult::QueueIsFull.
libethcore/Exceptions.h	Introduces TransactionQueueIsFull exception.
libethereum/Client.cpp	Passes stateNonce/allowFutureQueue into TQ import; throws TransactionQueueIsFull on QueueIsFull.
libweb3jsonrpc/Eth.cpp	Maps TransactionQueueIsFull to a user-facing RPC error string.
test/unittests/libethereum/TransactionQueue.cpp	Updates existing tests and adds new cases for CTQ-full fallback / FTQ limits / explicit rejection.
test/unittests/libethereum/SkaleHost.cpp	Updates test imports to new TQ import signature.
test/tools/libtesteth/BlockChainHelper.cpp	Updates helper queue imports to new TQ import signature.

[Copilot]

Pull request overview

Copilot reviewed 9 out of 9 changed files in this pull request and generated 4 comments.

[Copilot]

The class-level comment about blockedPromotions is hard to understand and has grammatical issues (e.g., “a FTQ that hasn't same sender in CTQ to be promoted”). Please rewrite this comment to clearly describe the invariant and the problem m_blockedPromotions solves (ideally with a short example).

Suggested change

	* Keeps track of a 'blockedPromotions' mapping used to keep track of txs that were tried
	* to be promoted from FTQ to CTQ, but CTQ was full at the time.
	* This is needed since we only promote FTQ txs from a specific sender that must be in CTQ.
	* blockedPromotions solves the case where a FTQ that hasn't same sender in CTQ to be promoted.
	*
	* FTQ transactions are promoted to CTQ only for senders that already have a transaction in CTQ.
	* This preserves per-sender nonce ordering while allowing promotion to start from the sender's
	* next executable transaction.
	*
	* `m_blockedPromotions` remembers FTQ transactions that were ready to move to CTQ but could not
	* be promoted because CTQ was full at that moment. Without this bookkeeping, promotion for that
	* sender could be missed later if the sender has no transaction left in CTQ to trigger another
	* promotion attempt.
	*
	* Example: sender A has nonce 5 in CTQ and nonce 6 in FTQ. If nonce 5 is removed and nonce 6 is
	* ready to be promoted, but CTQ is full, nonce 6 is recorded in `m_blockedPromotions` so it can
	* be retried once space becomes available.

[Copilot]

These lines look unformatted (missing spaces inside parentheses and a very long if condition). Since CI runs a clang-format check, please re-run clang-format on this file so the comparator block matches repository formatting and stays under the column limit.

[Copilot]

PR description says that when a tx is CTQ-eligible but CTQ is full, the queue will try to insert it into FTQ (when enabled). In this implementation, current-compatible transactions only attempt CTQ insertion and return QueueIsFull if CTQ has no capacity; only future-nonce transactions attempt FTQ insertion. Please align the PR description with the actual behavior, or implement the described CTQ->FTQ fallback here.