fix(iota-indexer): Get chain_identifier from chain_identifier table

[samuel-rufi]

Description of change

The current implementation of ReadApi::get_chain_identifier depends on IndexerReader::get_checkpoint to obtain the chain identifier. However, this approach fails when pruning is enabled, as the genesis checkpoint may no longer be available. To address this, the method should instead use IndexerReader::get_chain_identifier, which retrieves the chain identifier directly from the chain_identifier table.

Links to any relevant issues

Fixes #6156

Type of change

• Bug fix (a non-breaking change which fixes an issue)

How the change has been tested

Describe the tests that you ran to verify your changes.

Make sure to provide instructions for the maintainer as well as any relevant configurations.

• Basic tests (linting, compilation, formatting, unit/integration tests)
• Patch-specific tests (correctness, functionality coverage)

There is an existing ReadApi::get_chain_identifier test.
Furthermore, an additional test was added ReadApi::get_chain_identifier_with_pruning_enabled to test with pruning configuration.

Infrastructure QA (only required for crates that are maintained by @iotaledger/infrastructure)

• Synchronization of the indexer from genesis for a network including migration objects.
• Restart of indexer synchronization locally without resetting the database.
• Restart of indexer synchronization on a production-like database.
• Deployment of services using Docker.
• Verification of API backward compatibility.

The unchecked test classes have been left out as they are not relevant for this change.

Change checklist

Tick the boxes that are relevant to your changes, and delete any items that are not.

• I have followed the contribution guidelines for this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• I have checked that new and existing unit tests pass locally with my changes

Release Notes

• Protocol:
• Nodes (Validators and Full nodes):
• Indexer:
• JSON-RPC:
• GraphQL:
• CLI:
• Rust SDK:
• REST API:

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

4 Skipped Deployments

Name	Status	Preview	Comments	Updated (UTC)
apps-backend	⬜️ Ignored (Inspect)	Visit Preview		May 18, 2025 10:06am
apps-ui-kit	⬜️ Ignored (Inspect)			May 18, 2025 10:06am
rebased-explorer	⬜️ Ignored (Inspect)	Visit Preview		May 18, 2025 10:06am
wallet-dashboard	⬜️ Ignored (Inspect)	Visit Preview	💬 Add feedback	May 18, 2025 10:06am

[samuel-rufi]

While debugging, I noticed that the get_chain_identifier test gets flaky when running two cluster setups in the same process.

This happens because the global CHAIN_IDENTIFIER in the node is initialized once and reused across different cluster setups, which can cause inconsistent results.

Indexer tests involving the chain identifier need to take this into account.

The issue can be reproduced when running the existing get_chain_identifier test (which uses the cluster setup from the shared ApiTestSetup instance) with an additional cluster setup:

#[test]
fn get_chain_identifier() {
    let ApiTestSetup {
        runtime,
        cluster,
        store,
        client,
    } = ApiTestSetup::get_or_init();
    runtime.block_on(async move {
        indexer_wait_for_checkpoint(store, 1).await;

        let fullnode_chain_identifier = cluster.rpc_client().get_chain_identifier().await.unwrap();

        let indexer_chain_identifier = client.get_chain_identifier().await.unwrap();

        assert_eq!(fullnode_chain_identifier, indexer_chain_identifier)
    });
}

#[test]
fn get_chain_identifier_with_custom_setup() {
    let runtime = tokio::runtime::Runtime::new().unwrap();

    runtime.block_on(async move {
        let (cluster, store, client) = &start_test_cluster_with_read_write_indexer(
            Some("test_get_chain_identifier_with_custom_setup"),
            None,
            None,
        )
            .await;

        indexer_wait_for_checkpoint(store, 1).await;

        let fullnode_chain_identifier = cluster.rpc_client().get_chain_identifier().await.unwrap();
        let indexer_chain_identifier = client.get_chain_identifier().await.unwrap();

        assert_eq!(fullnode_chain_identifier, indexer_chain_identifier);
    })
}

Only one of the tests will pass:

cargo test --profile simulator --features shared_test_runtime --test rpc-tests read_api::get_chain_identifier

running 2 tests
test read_api::get_chain_identifier ... ok
test read_api::get_chain_identifier_with_custom_setup ... FAILED

running 2 tests
test read_api::get_chain_identifier ... FAILED
test read_api::get_chain_identifier_with_custom_setup ... ok

---

It's not an issue for this PR, however it indicates that we need to be aware of these globals when testing.
Tracking issue: #6902

[sergiupopescu199]

lgtm