web-client: Cannot request transaction history

[sisou]

Requesting tx history through the web-client for address NQ26 TT94 M4LL F8QS UH4M XPQK 9P42 QNH9 XVNY which has 94 transactions (92 pre-migration), I get this instead from all peers:

await $.client.getTransactionsByAddress("NQ26 TT94 M4LL F8QS UH4M XPQK 9P42 QNH9 XVNY")
...
2024-12-17T09:05:33.191000064Z DEBUG consensus_proxy      | Performing txn receipts by address request to peer peer_id=...
2024-12-17T09:05:33.297999872Z DEBUG consensus_proxy      | Obtained txn receipts response, length 500 
2024-12-17T09:05:33.300999936Z DEBUG consensus_proxy      | Performing txn proof request for block number block_number=5786280
2024-12-17T09:05:33.412000000Z DEBUG consensus_proxy      | We requested a transaction proof but the peer couldn't provide any peer=... error=too many transactions given
...
[]

I think there are two bugs here:
1. Why do all nodes return 500 receipts, when the address only has 94 transactions to its name?
2. Why can't peers not handle this maximum-receipts amount of transactions in a proof request?

[sisou]

Ok, turns out this address has over 500 transactions, as all the reward inherents (this address is a validator) count as transactions.

That leaves the problem of being unable to request proofs for so many txs in one requests

[sisou]

And I'm observing a new error now, too:

2024-12-17T10:12:03.039000000Z DEBUG consensus_proxy      | Performing txn proof request for block number block_number=5832000
2024-12-17T10:12:03.104000000Z DEBUG consensus_proxy      | We requested a transaction proof but the peer couldn't provide any peer=... error=requested txn proof from future block 5832000, current head is 5790358

The head block of the web-client doing the request was indeed ~5790358.

[sisou]

I think the reason for the (now) second problem is this:

core-rs-albatross/consensus/src/consensus/consensus_proxy.rs

Lines 280 to 285 in 15586d0

	if block_number <= &election_head.block_number() {
	// First Case: Transactions from finalized epochs
	hashes_by_block
	.entry(Some(Policy::election_block_after(*block_number)))
	.or_insert(vec![])
	.push(hash.clone());

The check is for lowerThan (block_number <= &election_head.block_number()), but Policy::election_block_after() returns the next election block number when given election block numbers.

So this fails for reward transactions, as they are in election blocks, but try to be proven with the next election block's number.