@subsquid/ponder 0.17.1-sqd.2

@subsquid/ponder@0.17.1-sqd.2

ponder@0.17.1 + the SQD Portal backfill layer, drop-in (bin stays ponder). This is a fork-side fix release on the same ponder@0.17.1 — the wiring patch and upstream version are unchanged from 0.17.1-sqd.1; only the Portal layer gained the fix below. It installs by default (--tag latest), superseding 0.17.1-sqd.1 (which now has no dist-tag — installable by exact version, npm i @subsquid/ponder@0.17.1-sqd.1).

Install: npm i @subsquid/ponder, or pin exact: npm i @subsquid/ponder@0.17.1-sqd.2.

What changed since 0.17.1-sqd.1 — factory query-sharding (#194, PR #195)

A factory whose discovered child-address set is large (~5.8k+) overflowed Portal's 256 KiB raw-query cap (MAX_RAW_QUERY_SIZE) in a single query body → Portal 400 → the fork's fail-loud turned that into a permanent hard stop for the chain. Batching + merge don't reduce the total body size, so above the wall the chain could not progress.

The fix — byte-budgeted log-query sharding. logQueryShards() partitions the merged log-request address union into multiple query bodies, each kept below the cap, streamed sequentially and unioned:

• Completeness preserved by construction (the Portal layer's INV-1 / INV-3 / INV-11 filter-completeness invariants): the shard loop lives inside the chunk's runStreams, so the chunk is cached/marked-done only after every shard has drained — no partial-commit window — and any shard error rejects the whole chunk and retries the full plan.
• Byte-identical no-op below the wall: when the whole body fits one shard the result is exactly one shard equal to the un-sharded query, so the entire existing validated corpus (≤ 872 children) is provably unaffected.
• A single merged element that alone exceeds the budget is now an attributable, up-front error rather than an opaque 400 at stream time.

Mutation-verified: a mutation that drops all-but-the-first shard (the silent-loss failure mode) turns the cross-shard completeness tests red.

Scope: historical-plane log/factory-child sharding. Realtime /stream sharding, factory→tx-filter sharding, and shard concurrency are tracked follow-ups (#196) — each retains a safe fail-loud (or the RPC-realtime fallback) today.

Compatibility

• Built + tested against ponder@0.17.1: scripts/sync-upstream.sh 0.17.1 --test — patch applies clean, tsc builds, 379 tests / 20 files green (adds portal/portal-shard.test.ts).
• Wiring patch and graft seam (HistoricalSync.syncBlockRangeData / syncBlockData) unchanged from 0.17.1-sqd.1; the fix is off-seam Portal-layer code (portal/portal-filters.ts, portal/portal.ts).
• Seam verified identical across 0.15.17–0.17.1 (compat.tested in versions.json).

---

Previous revision — 0.17.1-sqd.1 (upstream-parity bump)

No Portal-layer change — 0.17.1-sqd.1 was a pure upstream-parity bump. 0.17.0 → 0.17.1 is a single upstream performance PR (ponder-sh/ponder#2338, @kyscott18: "Improved sync performance by removing redundant block range constraints from event queries"), which narrows Ponder's internal trace/log read-back query (sync-store/index.ts, getEventData) to the block ranges of the filters active in each interval. That change sits downstream of the Portal fetch/insert and off the graft seam, so the rows the Portal writes are unchanged. portal/wiring/0.17.1.patch is a verbatim copy of portal/wiring/0.17.0.patch (sha256-equal, same 12 files).