airdrop.claims with fix from #3418

[hildobby]

…418)"

This reverts commit 478ef1d.

Brief comments on the purpose of your changes:

For Dune Engine V2

I've checked that:

General checks:

• I tested the query on dune.com after compiling the model with dbt compile (compiled queries are written to the target directory)
• I used "refs" to reference other models in this repo and "sources" to reference raw or decoded tables
• if adding a new model, I added a test
• the filename is unique and ends with .sql
• each sql file is a select statement and has only one view, table or function defined
• column names are lowercase_snake_cased
• if adding a new model, I edited the dbt project YAML file with new directory path for both models and seeds (if applicable)
• if wanting to expose a model in the UI (Dune data explorer), I added a post-hook in the JINJA config to add metadata (blockchains, sector/project, name and contributor Dune usernames)

Pricing checks:

• coin_id represents the ID of the coin on coinpaprika.com
• all the coins are active on coinpaprika.com (please remove inactive ones)

Join logic:

• if joining to base table (i.e. ethereum transactions or traces), I looked to make it an inner join if possible

Incremental logic:

• I used is_incremental & not is_incremental jinja block filters on both base tables and decoded tables
  • where block_time >= date_trunc("day", now() - interval '1 week')
• if joining to base table (i.e. ethereum transactions or traces), I applied join condition where block_time >= date_trunc("day", now() - interval '1 week')
• if joining to prices view, I applied join condition where minute >= date_trunc("day", now() - interval '1 week')

[hildobby]

Hey @jeff-dude, I added a schema value to each airdrop model to ensure those tables have the names they should, lmk if there is anything else I need to fix here!

[jeff-dude]

Hey @jeff-dude, I added a schema value to each airdrop model to ensure those tables have the names they should, lmk if there is anything else I need to fix here!

it's odd that in the original PR, the tests passed as expected, yet in prod it failed. likely since the spell already exists, then we're adding a bunch new & something is getting out of sync. i'll have to be careful and merge this one on it's own, so it's easy to monitor. i didn't see any glaring reason as to why the dependencies were broken.

[hildobby]

Hey @jeff-dude, I added a schema value to each airdrop model to ensure those tables have the names they should, lmk if there is anything else I need to fix here!

it's odd that in the original PR, the tests passed as expected, yet in prod it failed. likely since the spell already exists, then we're adding a bunch new & something is getting out of sync. i'll have to be careful and merge this one on it's own, so it's easy to monitor. i didn't see any glaring reason as to why the dependencies were broken.

sounds good, let me know if there's anything I can help with here

[jeff-dude]

Hey @jeff-dude, I added a schema value to each airdrop model to ensure those tables have the names they should, lmk if there is anything else I need to fix here!

it's odd that in the original PR, the tests passed as expected, yet in prod it failed. likely since the spell already exists, then we're adding a bunch new & something is getting out of sync. i'll have to be careful and merge this one on it's own, so it's easy to monitor. i didn't see any glaring reason as to why the dependencies were broken.

sounds good, let me know if there's anything I can help with here

looks like it ran fine now. the prod job had an --exclude tag:ens since we have a second job that lumped together ens/labels. i removed that exclusion and the missing dependency ran as expected. we will reorg our prod jobs to try to avoid this again