https://dagster.io/ logo
Join Slack
Powered by
:wave: dagster team! Another auto-materialization ...
# dagster-plus
h
👋 dagster team! Another auto-materialization related question. We've got a non-partitioned asset that's upstream of a daily partitioned asset. The purpose of the daily partitioned asset is to grab data with 
partition_date
from the non-partitioned asset and do something with it. The upstream asset can update multiple times a day and we'd expect that downstream, the current partition would auto-materialize every time it's upstream asset updates. However we only see it auto-materialize the first time the upstream asset updates and not for any updates after. Anything I can do to make the current partition update every time the upstream updates? Thanks for you help!
👀 1
s
@Henri Blancke do you have an eager or lazy policy on the partitioned asset? I would expect this to work if you use an eager policy The auto-materialization page in the asset's UI could help explain what is happening as well, could you share what that page looks like in this scenario?
h
@Sean Lopp an eager policy. This is what the UI looks like:
This particular asset had any or all of its upstream dependencies update at least 2-3 times today
s
ok I may need to tag in @owen for this one, but to confirm, are you on the latest version of dagster?
h
Yes we are on 1.4.4
o
Hi @Henri Blancke -- thanks for raising, we've seen another report of this behavior and are currently working on a fix!
🌈 1
❤️ 1
h
Thanks @owen
@owen another common issue we see with auto-materialization (and in this case dbt) is that dagster queues up materializations for assets that are already queued or running:
o
hm looking into this
hey @Henri Blancke ! I believe this bug had the same root cause as another issue that was patched for this week's release, and so I'd expect it to be resolved after this week's cloud push (tomorrow). Long story short, the logic to determine what work was currently in progress could break in some cases where assets had both regular assets and non-observable source assets as parents.
h
yay great news thanks @owen
@owen are you able to let us know when the push happens today 🙂? Thanks 🙏
o
It's scheduled for 4pm PST today, although that's more of an estimate than exact time (generally it is complete by 5pm PST)
h
Another issue we're experiencing is an asset being skipped for auto-materialization continuously even when the asset being waited on has been materialized a couple of hours ago. I see it most often for models that depend on a dbt seed (although not certain that is related):
Awesome thanks for the update @owen
o
for that issue, are you saying that there was some materialization of one of its parents that happened after 12:19pm, but is not represented here?
h
Yeah there was a materialization of one of the parents around 12pm (finished in <1min), yet at 3:40-50pm the materialization of the child was skipped because it is waiting on that parent
(aside from that, we have most of our dbt seeds set to a lazy auto-materialization policy, is that what is recommended?)
o
are they set with this policy so that they execute roughly on a schedule? that sounds fine to me
h
Yes, they do end up getting materialized a hand full of times a day because of downstream freshness policies
o
ah i see -- it's also reasonable to just put them in a job and run that job on an explicit cron schedule if you want more control there (this is something we're thinking about how to unify with the more declarative approach)
but re: the skipping issue, in that screenshot i'm not seeing any skipped evaluations, is it that one of the children had a skipped evaluation?
h
yeah we may end up reverting to that
yeah its the child that's being skipped because it is waiting on the parent (3+ hours after the parent materialized), so it keeps skipping auto-materialization even though the parent was updated
In the first screenshot you can see 
h_migrated_loan_first_installment_date
being waited on (the parent) in the 
loan / snapshot
(child). It has a ton of skipped conditions all waiting on the parent at various times after the parent was materialized
o
ah I see -- I missed the first screenshot
I'll look into this and get back to you, definitely odd
🙇 1
🙏 1
h
@owen I can confirm that our partitioned assets now seem to materialize correctly yay thanks 🙏
6 Views
Open in Slack
PreviousNext
Powered by