[GraphQL][DotMove][3/n] Adds External resolver

[manolisliolios]

Description

Introduces the external resolution, which requests "names" from a different graphql node.

In reality, that'll be a mainnet RPC endpoint being used.

Test plan

e2e tests updated to start a secondary service that utilizes external resolution, and depend on that:

cargo nextest run --package sui-graphql-rpc --test dot_move_e2e --features pg_integration

Stack

• [GraphQL][DotMove][2/n] Introduce typeByName #18797
• [GraphQL][DotMove][1/n] Introduces DotMove resolution #18774
• [GraphQL] Cache chain identifier & use ticks #18770

---

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):
• Indexer:
• JSON-RPC:
• GraphQL:
• CLI:
• Rust SDK:
• REST API:

[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	Aug 29, 2024 1:11pm

3 Skipped Deployments

Name	Status	Preview	Comments	Updated (UTC)
multisig-toolkit	⬜️ Ignored (Inspect)	Visit Preview		Aug 29, 2024 1:11pm
sui-kiosk	⬜️ Ignored (Inspect)	Visit Preview		Aug 29, 2024 1:11pm
sui-typescript-docs	⬜️ Ignored (Inspect)	Visit Preview		Aug 29, 2024 1:11pm

[amnn]

Very nice -- main comment here is related to distancing ourselves from the idea that external resolution always talks to mainnet.

[amnn]

This is good to go modulo nits, thanks @manolisliolios !

[amnn]

Here's a more compact way to do this:

Suggested change

	for k in mapping.keys() {
	// SAFETY: we inserted the keys in the mapping before.
	let idx = mapping.get(k).unwrap();
	let Some(Some(bcs)) = names.get(&fetch_key(idx)) else {
	continue;
	};
	let Some(bytes) = Base64::from_str(&bcs.value.bcs).ok() else {
	continue;
	};
	let Some(app_record) = bcs::from_bytes::<AppRecord>(&bytes.0).ok() else {
	continue;
	};
	// only insert the record if it is a valid `app_record`
	results.insert(k.clone(), app_record);
	}
	let results = HashMap::from_iter(
	mapping
	.into_iter()
	.filter_map(|k, idx| {
	let bcs = names.get(&fetch_key(idx))??;
	let Base64(bytes) = Base64::from_str(&bcs.value.bcs).ok()?;
	let app_record: AppRecord = bcs::from_bytes(&bytes).ok()?;
	Some((k, app_record))
	})
	);

Although I wonder whether if some of these steps fail, you should be producing an error instead, rather than dropping the value? Not sure -- that only works if the error can't be triggered by user input (i.e. it's an internal error of some kind.

[manolisliolios]

Thanks, love the more compact approach.

We'll error out when we try to populate things in the "controllers". Since this data loader is doing a bulk operation here (so it's likely that it is serving multiple requests), I didn't want irrelevant requests to error out that's why we ignore singular name errors on this layer.

It's a different story for full request errors, there we indeed do error out.

[amnn]

(But do take a look at the thing about using write! instead of .push_str(&format!(...))).