Factory child discovery can be falsely marked complete when reusing `ponder_sync` cache

[medariox]

Version

0.16.3

Current behavior

When reusing an existing ponder_sync, factory child discovery can be skipped even though it did not run for the current factory row. This causes child-address-based handlers to silently miss events.

Expected behavior

Factory discovery should be considered complete only from actual factory interval cache (factory_log_*), not inferred from log_*.

Steps to reproduce

Minimal example

• A parent contract emits ChildSet(address indexed child).
• Ponder uses factory(...) with parameter: "child" and indexes child event Child:Action.
• Cache is reused (ponder_sync) across deployments/restarts.
• DB ends up with log_* intervals present, but factory_log_* intervals empty for the current factory row.
  • This happens with factory identity changes (most commonly range change, but also parent address set change).
• On startup, the fallback above copies filterIntervals into factory intervals in memory.
• Historical sync computes no missing factory intervals.
• Child rediscovery is skipped.
• Child:Action events are not matched because child addresses are missing/incomplete.

Link to repository

No response

Anything else?

Relevant code block:
https://github.com/ponder-sh/ponder/blob/main/packages/core/src/sync-store/index.ts#L424-L447

  if (
    filterIntervals.length > 0 &&
    factoryIntervals.length === 0 &&
    filter.fromBlock === factory.fromBlock &&
    filter.toBlock === factory.toBlock
  ) {
    for (const factoryInterval of result.get(factory)!) {
      factoryInterval.intervals = filterIntervals;
    }
  }

This block infers factory discovery completeness from normal log filter completeness.
log_* cache progress is not equivalent to factory_log_* progress.
If this inference is wrong, runtime interval planning sees no missing factory intervals and skips rediscovery, so child addresses are not (re)inserted.

Proposed fix
Remove the fallback inference block above from getIntervals().
If legacy migration compatibility is still required, gate any fallback behind an explicit migration-version check, not runtime interval inference.

Workaround
Delete affected rows from:
ponder_sync.factory_addresses
ponder_sync.intervals for both matching factory_log_* and matching log_* fragments.
Then restart/resync.

---

As always, thank you for maintaining Ponder. Please let me know if you need anything else to help triage the issue.

[kyscott18]

Could you provide an example app, with the change to the factory commented out, so that I can try and reproduce this behavior?

The log_* interval should change when any of the configuration (including factory address) is updated.

ponder/packages/core/src/internal/types.ts

Lines 258 to 259 in a4a98fc

	/** log_{chainId}_{address}_{topic0}_{topic1}_{topic2}_{topic3}_{includeReceipts} */
	| `log_${number}_${FragmentAddressId}_${FragmentTopic}_${FragmentTopic}_${FragmentTopic}_${FragmentTopic}_${0 | 1}`

[medariox]

Hey, thanks for the quick reply!

I've invited you to this private repository, where I've set up a project that makes it easy to reproduce the bug.

If I understand correctly, this is exactly the issue: log_* changes if fields in its fragment key change (chainId, address/factory-address-id, topics, includeReceipts). It does not change for all configuration updates. In particular, fromBlock/toBlock and changing the same address to an array are not part of log_*.