Summary
In interchain-indexer/interchain-indexer-logic/src/indexer/avalanche/blockchain_id_resolver.rs, the in-memory cache used by BlockchainIdResolver::resolve only stores chain_id as the cache value. With the introduction of the force_add_chain parameter, DB persistence (ensuring a chains row exists and upserting into avalanche_icm_blockchain_ids) can be skipped or only partially completed (warnings are emitted but execution continues).
Problem
If a successful Data API lookup is memoized before DB persistence completes (or is skipped entirely), subsequent calls for the same blockchain_id will return the chain_id from cache without ever retrying the missing DB writes. This means the chains row and/or the avalanche_icm_blockchain_ids mapping can stay absent until cache eviction or service restart.
Suggested Fix
Either:
- Change the cache value type to encode persistence state (e.g.
{ chain_id: i64, persisted: bool }), and on a cache hit where force_add_chain == true and persisted == false, re-run the persistence path; or
- On a cache hit, when
force_add_chain == true, always re-run the persistence path outside of try_get_with (accepting some redundant upsert attempts) to guarantee eventual consistency.
Warning/partial-failure paths should ensure the state reflects that persistence has not yet completed so subsequent calls retry.
References
/cc @EvgenKor
Summary
In
interchain-indexer/interchain-indexer-logic/src/indexer/avalanche/blockchain_id_resolver.rs, the in-memory cache used byBlockchainIdResolver::resolveonly storeschain_idas the cache value. With the introduction of theforce_add_chainparameter, DB persistence (ensuring achainsrow exists and upserting intoavalanche_icm_blockchain_ids) can be skipped or only partially completed (warnings are emitted but execution continues).Problem
If a successful Data API lookup is memoized before DB persistence completes (or is skipped entirely), subsequent calls for the same
blockchain_idwill return thechain_idfrom cache without ever retrying the missing DB writes. This means thechainsrow and/or theavalanche_icm_blockchain_idsmapping can stay absent until cache eviction or service restart.Suggested Fix
Either:
{ chain_id: i64, persisted: bool }), and on a cache hit whereforce_add_chain == trueandpersisted == false, re-run the persistence path; orforce_add_chain == true, always re-run the persistence path outside oftry_get_with(accepting some redundant upsert attempts) to guarantee eventual consistency.Warning/partial-failure paths should ensure the state reflects that persistence has not yet completed so subsequent calls retry.
References
/cc @EvgenKor