Background
fetch.rs hard-codes the lists of topics it queries for orderbook and interpreter store events. When new events are added or ABI hashes change, developers must edit the fetcher directly, mixing transport logic with contract-specific concerns.
Problem
Coupling transport logic to topic definitions makes the fetch module harder to evolve and introduces a long-term maintenance risk: updating topics requires touching low-level fetch code, and alternative fetchers cannot easily supply their own topic sets.
Proposed Approach
- Define the event topics alongside their corresponding ABI bindings (or in a dedicated constants module) so they live near the contract definitions.
- Update
LocalDb fetch entry points to accept topics as parameters (or pull them from the new constants module) instead of embedding raw hashes.
- Ensure higher-level callers (order sync, store sync) select the appropriate topic sets, keeping the fetch logic transport-focused and easier to reuse.
Background
fetch.rshard-codes the lists of topics it queries for orderbook and interpreter store events. When new events are added or ABI hashes change, developers must edit the fetcher directly, mixing transport logic with contract-specific concerns.Problem
Coupling transport logic to topic definitions makes the fetch module harder to evolve and introduces a long-term maintenance risk: updating topics requires touching low-level fetch code, and alternative fetchers cannot easily supply their own topic sets.
Proposed Approach
LocalDbfetch entry points to accept topics as parameters (or pull them from the new constants module) instead of embedding raw hashes.