ledger_api: get_transaction_receipt performative missing kwargs field causes spurious "Incorrect number of contents" ERROR on multi-chain receipt requests

[LOCKhart07]

Description

The ledger_api protocol's get_transaction_receipt performative does not declare a kwargs field, but the surrounding tooling sends a kwargs content on that performative to thread a chain_id for multi-chain receipt fetching. As a result the message fails its own consistency check and the protocol logs an ERROR on every receipt request that carries a chain_id:

[ERROR] Incorrect number of contents. Expected 3. Found 4

It is benign — the receipt is still fetched and validation succeeds immediately afterwards — but it produces a constant stream of spurious ERROR log lines (one per transaction validation), which is noisy and misleading in production logs.

Root cause

The get_transaction_receipt performative in the ledger_api protocol spec only models three contents:

get_transaction_receipt:
  transaction_digest: ct:TransactionDigest
  retry_timeout: pt:optional[pt:int]
  retry_attempts: pt:optional[pt:int]

So the generated LedgerApiMessage._is_consistent() caps expected_nb_of_contents at 3 for this performative (packages/valory/protocols/ledger_api/message.py):

elif self.performative == LedgerApiMessage.Performative.GET_TRANSACTION_RECEIPT:
    expected_nb_of_contents = 1                      # transaction_digest
    if self.is_set("retry_timeout"):
        expected_nb_of_contents += 1                 # -> 2
    if self.is_set("retry_attempts"):
        expected_nb_of_contents += 1                 # -> 3
    # no handling for `kwargs`

However, the message is constructed with a fourth content, kwargs, to carry chain_id (this happens in open-autonomy's abstract_round_abci _send_transaction_receipt_request, mirroring how get_state / send_signed_transaction thread chain selection):

ledger_api_dialogues.create(
    counterparty=LEDGER_API_ADDRESS,
    performative=LedgerApiMessage.Performative.GET_TRANSACTION_RECEIPT,
    transaction_digest=...,
    retry_timeout=retry_timeout,
    retry_attempts=retry_attempts,
    kwargs=LedgerApiMessage.Kwargs(kwargs),   # chain_id rides here
)

With transaction_digest + retry_timeout + retry_attempts + kwargs all set, the message has 4 contents but the performative spec allows 3 → AEAEnforceError → _default_logger.error("Incorrect number of contents. Expected 3. Found 4").

Notably, the sibling initiation performatives get_state, send_signed_transaction, and send_signed_transactions already declare kwargs: ct:Kwargs — get_transaction_receipt is the odd one out, which is exactly what's needed for multi-chain chain selection.

Proposed fix

Add an (optional) kwargs field to the get_transaction_receipt performative in the ledger_api protocol specification, regenerate the protocol, and ensure the ledger connection reads chain_id from kwargs for receipt requests (consistent with the other performatives):

get_transaction_receipt:
  transaction_digest: ct:TransactionDigest
  retry_timeout: pt:optional[pt:int]
  retry_attempts: pt:optional[pt:int]
  kwargs: ct:Kwargs

Impact

• Severity: low (cosmetic / log noise), but high frequency — one ERROR per transaction validation.
• Observed on a Polygon (multi-chain) deployment where get_transaction_receipt is always called with chain_id.
• Confuses log monitoring / alerting since it is logged at ERROR level despite being harmless.