@aztec/pxe 5.0.0 → 5.0.1

package/src/storage/tagging_store/sender_tagging_store.ts

@@ -128,10 +128,11 @@ export class SenderTaggingStore implements StagedStore {
   }
 
   /**
-   * Stores pending index ranges.
+   * Stores pending index ranges, rejecting any range that disagrees with an already-stored one.
    * @remarks If the same (secret, txHash) pair already exists in the db with an equal range, it's a no-op. This is
    * expected to happen because whenever we start sync we start from the last finalized index and we can have pending
-   * ranges already stored from previous syncs. If the ranges differ, it throws an error as that indicates a bug.
+   * ranges already stored from previous syncs. If the ranges differ, it throws an error as that indicates a bug in
+   * callers that record indexes at prove time. Discovery from onchain logs must use `mergePendingIndexes` instead.
    * @param ranges - The tagging index ranges containing the directional app tagging secrets and the index ranges that are
    * to be stored in the db.
    * @param txHash - The tx in which the tagging indexes were used in private logs.
@@ -141,6 +142,33 @@ export class SenderTaggingStore implements StagedStore {
    * @throws If a different range already exists for the same (secret, txHash) pair.
    */
   storePendingIndexes(ranges: TaggingIndexRange[], txHash: TxHash, jobId: string): Promise<void> {
+    return this.#storePendingIndexes(ranges, txHash, jobId, false);
+  }
+
+  /**
+   * Stores pending index ranges, widening an existing entry for the same (secret, txHash) pair to the union of the
+   * stored and incoming ranges instead of throwing on a mismatch. Discovery from onchain logs needs this: it may see
+   * only the surviving (non-revertible phase) sub-range of a partially reverted tx recorded at prove time (the
+   * finalized receipt step of the sync resolves that difference), or indexes beyond a partially discovered entry
+   * when a tx from another PXE straddles a sync window boundary. Callers that record indexes at prove time must use
+   * `storePendingIndexes` instead, so that a range disagreement surfaces as a bug rather than being absorbed.
+   * @param ranges - The tagging index ranges containing the directional app tagging secrets and the index ranges that are
+   * to be stored in the db.
+   * @param txHash - The tx in which the tagging indexes were used in private logs.
+   * @param jobId - job context for staged writes to this store. See `JobCoordinator` for more details.
+   * @throws If the highestIndex is further than window length from the highest finalized index for the same secret.
+   * @throws If the lowestIndex is lower than or equal to the last finalized index for the same secret.
+   */
+  mergePendingIndexes(ranges: TaggingIndexRange[], txHash: TxHash, jobId: string): Promise<void> {
+    return this.#storePendingIndexes(ranges, txHash, jobId, true);
+  }
+
+  #storePendingIndexes(
+    ranges: TaggingIndexRange[],
+    txHash: TxHash,
+    jobId: string,
+    mergeExisting: boolean,
+  ): Promise<void> {
     if (ranges.length === 0) {
       return Promise.resolve();
     }
@@ -187,21 +215,40 @@ export class SenderTaggingStore implements StagedStore {
         // Check if an entry with the same txHash already exists
         const existingEntry = pendingData.find(entry => entry.txHash === txHashStr);
 
-        if (existingEntry) {
-          // Assert that the ranges are equal — different ranges for the same (secret, txHash) indicates a bug
-          if (existingEntry.lowestIndex !== range.lowestIndex || existingEntry.highestIndex !== range.highestIndex) {
-            throw new Error(
-              `Conflicting range for secret ${secretStr} and txHash ${txHashStr}: ` +
-                `existing [${existingEntry.lowestIndex}, ${existingEntry.highestIndex}] vs ` +
-                `new [${range.lowestIndex}, ${range.highestIndex}]`,
-            );
-          }
-          // Exact duplicate — skip
-        } else {
-          this.#writePendingIndexes(jobId, secretStr, [
+        let updatedPending: PendingIndexesEntry[] | undefined;
+        if (!existingEntry) {
+          updatedPending = [
             ...pendingData,
             { lowestIndex: range.lowestIndex, highestIndex: range.highestIndex, txHash: txHashStr },
-          ]);
+          ];
+        } else if (mergeExisting) {
+          // Widen the entry to the union of both ranges, never shrink it: replacing would drop prove-time
+          // indexes the chain doesn't show (partially reverted tx), and skipping would drop onchain indexes
+          // discovered in a later sync window (tx straddling the window boundary).
+          const lowestIndex = Math.min(existingEntry.lowestIndex, range.lowestIndex);
+          const highestIndex = Math.max(existingEntry.highestIndex, range.highestIndex);
+          if (lowestIndex !== existingEntry.lowestIndex || highestIndex !== existingEntry.highestIndex) {
+            updatedPending = pendingData.map(entry =>
+              entry === existingEntry ? { lowestIndex, highestIndex, txHash: entry.txHash } : entry,
+            );
+          }
+        } else if (
+          existingEntry.lowestIndex !== range.lowestIndex ||
+          existingEntry.highestIndex !== range.highestIndex
+        ) {
+          // Different ranges for the same (secret, txHash) indicate a bug in callers that record indexes at prove
+          // time.
+          throw new Error(
+            `Conflicting range for secret ${secretStr} and txHash ${txHashStr}: ` +
+              `existing [${existingEntry.lowestIndex}, ${existingEntry.highestIndex}] vs ` +
+              `new [${range.lowestIndex}, ${range.highestIndex}]`,
+          );
+        }
+        // Remaining cases (a merge whose union equals the stored range, or an identical range without
+        // mergeExisting): duplicate evidence, nothing to write.
+
+        if (updatedPending) {
+          this.#writePendingIndexes(jobId, secretStr, updatedPending);
         }
       }
     });

package/src/tagging/sender_sync/sync_sender_tagging_indexes.ts

@@ -74,7 +74,7 @@ export async function syncSenderTaggingIndexes(
     }
 
     // Receipts for pending tx hashes that the logs query just surfaced still need a sequential follow-up call.
-    // `storePendingIndexes` is idempotent on (secret, txHash), so a re-discovered hash stays classified as known
+    // `mergePendingIndexes` is idempotent on (secret, txHash), so a re-discovered hash stays classified as known
     // and is not re-fetched here.
     const knownSet = new Set(knownPendingTxHashes.map(h => h.toString()));
     const newPendingTxHashes = allPendingTxHashes.filter(h => !knownSet.has(h.toString()));

package/src/tagging/sender_sync/utils/load_and_store_new_tagging_indexes.ts

@@ -36,11 +36,15 @@ export async function loadAndStoreNewTaggingIndexes(
   const txsForTags = await getTxsContainingTags(siloedTagsForWindow, aztecNode, anchorBlockHash);
   const txIndexesMap = getTxIndexesMap(txsForTags, start, siloedTagsForWindow.length);
 
-  // Now we iterate over the map, construct the tagging index ranges and store them in the db.
+  // Now we iterate over the map, construct the tagging index ranges and store them in the db. A tx already tracked
+  // in the store is merged rather than range-checked: if this PXE sent the tx and it partially reverted, the chain
+  // only shows the surviving sub-range of the prove-time entry (the finalized receipt step of the sync owns
+  // resolving that difference), and a tx from another PXE may straddle a sync window boundary, in which case the
+  // entry is widened so the next index choice covers the full onchain range.
   for (const [txHashStr, indexes] of txIndexesMap.entries()) {
     const txHash = TxHash.fromString(txHashStr);
     const ranges = [{ extendedSecret, lowestIndex: Math.min(...indexes), highestIndex: Math.max(...indexes) }];
-    await taggingStore.storePendingIndexes(ranges, txHash, jobId);
+    await taggingStore.mergePendingIndexes(ranges, txHash, jobId);
   }
 }