Options for how asset checks could appear in the asset graph UI

[sryza]

Separate bubble

Merged with asset node

[alex-orlovskyi]

IMO separate bubbles look better ^_^
P.S. After reading RFC - +1 point to separate bubbles: it also makes subconscious feeling, that check is a separate process/entity, which is attached/having close relationship to main entity.

[mjkanji]

I think I prefer the combined option (merged with asset node).

Though, I think the best set up would be to not add any vertical height and add the information in the existing space:

1. Condense the text to just be x / y instead of x of y checks passed.
2. Add this shorter blurb (with a tick or a crossmark) to either:
   • the same line as the asset name (aligned right)
   • new bubble on the same line as the compute_type bubbles (with a similar design)
   • the same line as "Upstream data changed", aligned right

[Beaglefoot]

Is it a new concept or something related to DagsterType checks?

[sryza]

This is a new concept. The differences are:

• Unlike asset checks, Dagster type checks run before the output is persisted to storage. So if the output corresponds to an asset and the type check fails, the asset won't be materialized.
• Unlike asset checks, Dagster type checks can be applied to inputs.
• Unlike asset checks, Dagster type checks on an output always run in the same op as the op producing the output.
• Unlike asset checks, Dagster type checks only make sense when you're using IO managers.
• Unlike asset checks, Dagster type checks can be used if you're using non-asset jobs and ops.

[prratek]

I prefer the second (merged) option because to me because, like the freshness status or when the asset was last materialized, asset check results communicate information about the current state of an asset. Makes sense to treat them the same way.