fix(pxe): Batch getLogsByTags calls in syncTaggedLogs to prevent RPC limit errors

[porco-rosso-j]

Title

fix(pxe): Batch getLogsByTags calls in syncTaggedLogs to prevent RPC limit errors

Description

Problem

When simulating or proving transactions, users encounter the error:

Array must contain at most 100 element(s) (0)

I've been getting this error from time to time in both node and browser environments, and it looks like that this has been known problem a few other people have also encountered.

• case 1
• case 2

This error occurs inconsistently and becomes more likely as the PXE handles more accounts and contracts during a session.

Root Cause

In syncTaggedLogs, tags are generated for all registered senders and passed to getLogsByTags in a single RPC call. The Aztec Node enforces a MAX_RPC_LEN = 100 limit on array arguments via Zod validation.

The tag count grows as: number_of_senders × ~11 tags_per_sender

Evidence from test logs:

Senders	Tags	Result
6	66	✅
7	77	✅
8	88	✅
9	99	✅
10	110	❌ Array must contain at most 100 element(s)

As more accounts/contracts are registered with the PXE during test execution, the sender list grows, eventually exceeding the 100 tag limit.

Code Path

syncTaggedLogs()
  → this.#getSenders(scopes)           // Returns ALL registered senders
  → for (sender of senders) { ... }    // Generates ~11 tags per sender
  → this.#getPrivateLogsByTags(tags)   // Sends ALL tags in ONE RPC call ❌

Solution

Add batching to #getPrivateLogsByTags to chunk tag arrays into batches of MAX_RPC_LEN (100) before making RPC calls.

This follows the existing pattern used by syncNoteNullifiers, which already correctly batches its findLeavesIndexes calls.

Changes

• #getPrivateLogsByTags: Batch tags into chunks of 100, make multiple RPC calls, merge results

Testing

• Verified with E2E tests that have registered 10+ senders in pxe's taggingDataProvider
• Previously failing tests now pass without hitting the RPC limit

[benesjan]

@porco-rosso-j we are completely replacing the syncTaggedLogs function and first of the PR doing that is here so unfortunately it doesn't make sense to merge this.

In the new algo I compute the tags individually for each sender-recipient pair and the correct solution there is to just have the max index window length be the MAX_RPC_LEN limit. This is not yet the case but I will implement it.

Thanks for the contribution!