change UI to narrow asset events query

[prha]

Summary & Motivation

This PR simplifies the data fetching for metadata plots in a couple ways.

Before:
For partitioned assets, we were using the partitionInLast parameter to filter materializations. This fetches all partition keys (expensive), and then grabs the last N materializations that show up in the last N partitions* (incorrect). We were also fetching the materialization in the most recent partition to represent the most recent materialization overall.

• This incorrectness is better documented here: RFC: map partitionInLast parameter to latestMaterializationByPartition #25696

After:
We separate out the most recent materialization query to be just that, fetch the most recent materialization regardless of partition (this may or may not be the right decision, based on product, but it's easy to change). For partitioned assets, we now do a two-phased fetch. We first fetch the last N partition keys, using the new paginated partition key graphql fields. We then use those partition keys to pass into the latestMaterializationByPartition field, which gets the most recent materialization for the provided set of partition keys.

Breaking apart the partition history data fetching to be closer to the graphs component also means that the main components become interactive much earlier.

This should result in better correctness and massively reduce overfetching. This should also result in much better performance in Cloud.

How I Tested These Changes

Screen.Recording.2025-03-31.at.2.48.50.PM.mov

Changelog

[prha]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• remove partition view on asset events for non-sda assets #28941
• change UI to narrow asset events query #28903 👈 (View in Graphite)
• add paginated partition key graphql fields to partitioned asset nodes #28774
• add dynamic store connection APIs #28655
• partition key pagination APIs #28311
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

[github-actions]

Deploy preview for dagit-core-storybook ready!

✅ Preview
https://dagit-core-storybook-anvt13wgm-elementl.vercel.app
https://prha-ui-partition-keys.core-storybook.dagster-docs.io

Built with commit 9d25a61.
This pull request is being automatically deployed with vercel-action

[graphite-app]

It appears the rendering logic is reversed from what the variable names suggest. When plotView === 'partition', the code renders <AssetTimeMetadataPlots>, and when plotView is something else (presumably 'time'), it renders <AssetPartitionMetadataPlots>.

For clarity and consistency with the variable names, this should be swapped so that:

• When plotView === 'partition', render <AssetPartitionMetadataPlots>
• When plotView === 'time', render <AssetTimeMetadataPlots>

This would align the component rendering with the user's selection in the ButtonGroup above.

Suggested change

	plotView === 'partition' ? (
	<AssetTimeMetadataPlots assetKey={assetKey} limit={100} />
	) : (
	<AssetPartitionMetadataPlots assetKey={assetKey} limit={120} />
	)
	plotView === 'partition' ? (
	<AssetPartitionMetadataPlots assetKey={assetKey} limit={120} />
	) : (
	<AssetTimeMetadataPlots assetKey={assetKey} limit={100} />
	)

Spotted by Diamond

Is this helpful? React 👍 or 👎 to let us know.

[bengotow]

Oh I guess Graphite agrees! Wow interesting

[bengotow]

This looks awesome - left a few inline comments! I didn't realize that fetching the partition keys and then passing them in explicitly would be so much better, that's great :-o

[bengotow]

Oh I guess Graphite agrees! Wow interesting

[bengotow]

Don't think it's worth changing but if you want, you can also express this as filter(Boolean) (running each through the Boolean typecast essentially)

[graphite-app]

There appears to be an issue with partition key ordering in this code. The partition keys go through multiple reversals which could lead to incorrect ordering in the UI:

1. LATEST_ASSET_PARTITIONS_QUERY fetches keys in descending order with ascending: false
2. useLatestAssetPartitionMaterializations reverses them with [...partitionKeys].reverse()
3. The groupByPartition function (not shown here) likely reverses them again with const orderedPartitionKeys = [...definedPartitionKeys].reverse()

This triple transformation is confusing and could cause unexpected behavior. Consider either:

• Removing the .reverse() call in useLatestAssetPartitionMaterializations
• Updating the groupByPartition function to account for the already-reversed order

A clearer approach would be to establish a consistent ordering convention throughout the codebase and minimize transformations.

Suggested change

	const {partitionKeys} = useLatestAssetPartitions(assetKey, limit);
	return useAssetPartitionMaterializations(assetKey, [...partitionKeys].reverse());
	const {partitionKeys} = useLatestAssetPartitions(assetKey, limit);
	return useAssetPartitionMaterializations(assetKey, partitionKeys);

Spotted by Diamond

Is this helpful? React 👍 or 👎 to let us know.

[prha]

This looks awesome - left a few inline comments! I didn't realize that fetching the partition keys and then passing them in explicitly would be so much better, that's great :-o

Yeah, it's not the fact that prefetching is so much better. It's the fact that we were using resolvers on the GrapheneAsset before, and we're now using resolvers on the GrapheneAssetNode (the difference between assetOrError vs assetNodeOrError). The latter has access to the definition, which makes it much easier to grab the last N partitions and query the materializations cheaply by them. The former does not and thus has to scan through history.

We were also using the same query to generate graphs for the case where there is an asset definition and the case where there is not. This means that we were doing the inefficient fetch for both. This PR (and #28941) changes the query for the definition-based query to use the more efficient fetch and removes the UI altogether for the non-definition case.