Default token mints subscriptions, killer for public rpc and private pools

[Arrowana]

Every single token mint in spl-token-registry is added to the cache

dapp-scaffold/src/contexts/connection.tsx

Lines 97 to 125 in 9352c93

	const [tokenMap, setTokenMap] = useState<Map<string, TokenInfo>>(new Map());
	useEffect(() => {
	cache.clear();
	// fetch token files
	(async () => {
	const res = await new TokenListProvider().resolve();
	const list = res
	.filterByChainId(chain.chainID)
	.excludeByTag("nft")
	.getList();
	const knownMints = list.reduce((map, item) => {
	map.set(item.address, item);
	return map;
	}, new Map<string, TokenInfo>());
	const accounts = await getMultipleAccounts(connection, [...knownMints.keys()], 'single');
	accounts.keys.forEach((key, index) => {
	const account = accounts.array[index];
	if(!account) {
	return;
	}
	cache.add(new PublicKey(key), account, MintParser);
	})
	setTokenMap(knownMints);
	setTokens(list);
	})();
	}, [connection, chain]);

Adding to the cache has a side effect, creating a subscription to the added account:

dapp-scaffold/src/contexts/accounts.tsx

Lines 361 to 371 in eef68f4

	useEffect(() => {
	const subs: number[] = [];
	cache.emitter.onCache((args) => {
	if (args.isNew) {
	let id = args.id;
	let deserialize = args.parser;
	connection.onAccountChange(new PublicKey(id), (info) => {
	cache.add(id, info, deserialize);
	});
	}
	});

This problem is invisible on devnet as the token list is small, but once plugged to mainnet this is a node/rpcpool killer as the code will open a great number of account subscriptions through onAccountChange

In most cases an up to date token mint is not required, only in rare cases it is useful (LP token supply...).

This should be reworked so the dapp-scaffold boilerplate is not a trap.

Here is a screenshot of the swarm of accountSubscribe in the websocket, it can't even fit on the screen

Some of which are essential tokens to be monitored

[brianlong]

I'll upvote the importance of this issue. We have now seen multiple cases where developers started with this scaffold and later saw disastrous results on their mainnet launch. Blindly opening this many subscriptions is an anti-pattern to be avoided.

A safer approach might be for the developer to explicitly state the subscriptions they require.

// @bartosz-lipinski @rmshea

[joeaba]

'+ @bhgames

[aaronovz1]

Can confirm this is a node killer. It's better to get rid of subscriptions altogether and just poll at reasonable frequencies using getMultipleAccounts to batch as much as you can.

[kevinrodriguez-io]

I'll take a look into this.