[indexer-alt][db-agnostic framework][3/n] Apply generic changes to concurrent pipelines

[wlmyng]

Description

Apply same changes on sequential pipelines (#21537) to concurrent pipelines.

Test plan

How did you test the new or updated feature?

---

Release notes

Check each box that your changes affect. If none of the boxes relate to your changes, release notes aren't required.

For each box you select, include information after the relevant heading that describes the impact of your changes that a user might notice and any actions they must take to implement updates.

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

[vercel]

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

Name	Status	Preview	Comments	Updated (UTC)
sui-docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Apr 4, 2025 9:22pm

2 Skipped Deployments

Name	Status	Preview	Comments	Updated (UTC)
multisig-toolkit	⬜️ Ignored (Inspect)	Visit Preview		Apr 4, 2025 9:22pm
sui-kiosk	⬜️ Ignored (Inspect)	Visit Preview		Apr 4, 2025 9:22pm

[amnn]

Looks good to me, but needs some clean ups:

• Within all the handler implementations, we should now have to use the <_ as Store>::Connection syntax -- just refer to the concrete type. If that's not possible then let's talk about how to make that possible, because it's going to be annoying for builders otherwise.
• nit: be consistent about whitespace in Handler impls (empty line after type Store = Db).
• nit (optional): add a type alias for the connection of a store to avoid having to use the <_ as Store>::Connection<'_> syntax everywhere -- this is probably not worth it though if most Handlers don't have to use this syntax.

[amnn]

Note that there should be two impl blocks for Indexer -- one with an S: Store constraint that exposes concurrent_pipeline and another with an S: TransactionalStore constraint that exposes sequential_pipeline.

[wlmyng]

That makes sense

[amnn]

(optional): I did some digging into why this explicit trait constraining is required, it's just a limitation of the type system: rust-lang/rust#38078.

And it's not a big deal in this case (it's not too difficult to understand what's going on), but there was a nice workaround suggested in the issue, which is to introduce a type alias:

type StoreConnection<'a, S> = <S as Store>::Connection<'a>;

Which can be used here (and elsewhere) to refer to the nested associated connection type for a store associated type.

[amnn]

Within handlers, I think it's fine (preferred) to refer to the Connection directly on the concrete store type:

Suggested change

	conn: &mut <Self::Store as Store>::Connection<'a>,
	conn: &mut Db::Connection<'a>,

or (if there are two associated Connection types for Db):

Suggested change

	conn: &mut <Self::Store as Store>::Connection<'a>,
	conn: &mut db::Connection<'a>,

But probably if that's the case the better thing to do would be to remove the previously introduced associated type, because it was probably trying to achieve the same thing that the Store trait is achieving now.

[wlmyng]

The other connection type comes from pub type Connection<'p> = PooledConnection<'p, AsyncPgConnection>; in sui_pg_db, so a convenience type alias? Even if we were to rename this though, Rust still complains about ambiguous associated type if we try to reference Db::Connection in the handler. Actually, I don't think sui_pg_db::Connection is associated at all to the Db, the association comes from implementing Store on Db? So rust is complaining that there's a possibility for multiple Store to be implemented for diff Connection. Which is why when we reference db::Connection the complaint goes away. This works in our favor since we want handler impl to refer to the concrete type anyways