Unsynced Status Is Not Being Propagated Down The Lineage

[bolinzzz]

Hi team, we often use "Materialize unsynced" to bulk run downstream assets of a failed asset. However, after upgraded to version 1.8.10, we noticed that the unsynced status stops at the level one children, instead of propagating down the lineage graph. Please refer to the screenshot

• vouchers is unsynced because base__rewards__applied_voucher.. was updated after vouchers had run at 04:29.
• I would expect both recurring_dd_campaign and recurring_dd_campaign_aug_2024 to be labeled as unsynced.

Please shed a light on how to reinstate the old behaviour of "Materialize unsynced"

[cyberjar09]

we are affected too. Also on 1.8.10 OSS

[garethbrickman]

I think this was an intentional change in 1.8.0:

The “Unsynced” label on an asset is no longer transitive, i.e. it no longer displays purely on account of a parent asset being labeled “Unsynced”. This helps avoid “Unsynced label fatigue”, where huge portions of the graph often have the label because of a distant ancestor. And it also helps the asset graph UI load faster.

[Terroface]

@garethbrickman it would be really useful to be able to materialize unsynced and downstream. Is there another way to accomplish this now?

The use case: a code change on one asset may affect its children. Being able to run all the changes and all downstream assets through the UI would save us time and compute. Currently, the only way to ensure all changes have propagated through is to run entire jobs.

[zach-hunt]

Here's what I do as a workaround,

• Look for Unsynced asset tags
• Select the Parent and Show downstream graph
• Materialize All

But, this does not work with multi-select, so it's only effective if all modified assets have a common parent.

Edit: You can achieve multiselect if you know which assets changed by searching
key:"MODIFIED_ASSET_A"+ or key:"MODIFIED_ASSET_B"+