Initialize elementary graph even if disabled

[yu-iskw]

I encountered the error, if Elementary is disabled at the version of 0.20.1. I think it would be good to initialize the elementary graph, even though Elementary is disabled.

dbt-data-reliability/macros/edr/materializations/test/test.sql

Line 211 in 1f753cb

{% do elementary.get_cache("elementary_test_results").update({model.unique_id: elementary_test_results_rows}) %}

06:05:00  Failure in test accepted_values_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx_flag__False__True__False (models/xxxx/xxxx/xxxx/schema.yml)
06:05:00    Compilation Error in test accepted_values_xxxxxxxxxxxxxxxxxxxxxxxxxxx_flag__False__True__False (models/xxx/xxx/xxx/schema.yml)
  'None' has no attribute 'update'

  > in macro handle_dbt_test (macros/edr/materializations/test/test.sql)
  > called by macro materialize_test (macros/edr/materializations/test/test.sql)
  > called by macro materialization_test_default (macros/edr/materializations/test/test.sql)

Summary by CodeRabbit

• Refactor
  • Initialization now occurs unconditionally at the very start of startup, simplifying startup flow.
• Bug Fixes
  • Prevents startup from skipping initialization in some early-exit cases, improving runtime and test reliability.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

📝 Walkthrough

Walkthrough

An initialization call for the elementary graph in the on_run_start dbt macro was moved to the very start of the macro, made unconditional, and the duplicate later initialization was removed; the is_elementary_enabled() check now runs after this initialization.

Changes

Cohort / File(s)	Summary
Initialization Sequencing macros/edr/system/hooks/on_run_start.sql	Moved elementary graph initialization to execute unconditionally at the macro's beginning; removed the later duplicate initialization. Logging and runtime construction remain unchanged; control flow now performs initialization before is_elementary_enabled() early return.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Poem

🐰 I hopped to the start with a bright little cheer,
One gentle init — now tidy and clear.
No echoes of two, just a single new start,
The graph wakes up, light in its heart. ✨

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately reflects the main change: initializing the elementary graph unconditionally, even when Elementary is disabled.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

📜 Recent review details

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Disabled knowledge base sources:

• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between 8cf1432 and 6c34eae.

📒 Files selected for processing (1)

• macros/edr/system/hooks/on_run_start.sql

🧰 Additional context used

🧠 Learnings (1)

📓 Common learnings

Learnt from: arbiv
Repo: elementary-data/dbt-data-reliability PR: 861
File: macros/edr/tests/test_utils/clean_elementary_test_tables.sql:45-50
Timestamp: 2025-09-15T06:06:05.601Z
Learning: In the Elementary dbt-data-reliability codebase, the team prefers simpler, direct approaches over creating helper macros for centralized quoting logic, even when it might provide better maintainability across multiple use cases. They value code simplicity and readability over abstraction.

Learnt from: GuyEshdat
Repo: elementary-data/dbt-data-reliability PR: 838
File: macros/utils/table_operations/delete_and_insert.sql:138-146
Timestamp: 2025-08-10T11:29:06.982Z
Learning: In the Elementary dbt-data-reliability codebase, the team prefers to add the `escape_reserved_keywords` macro only in places where they've actually encountered errors with reserved keywords, rather than preemptively adding it everywhere. They rely on E2E tests to catch future issues if reserved keywords cause problems in untested code paths. This pragmatic approach avoids unnecessary defensive programming and keeps the codebase simpler.

Learnt from: haritamar
Repo: elementary-data/dbt-data-reliability PR: 827
File: macros/utils/cross_db_utils/generate_elementary_profile_args.sql:30-31
Timestamp: 2025-07-27T11:33:35.918Z
Learning: In the Elementary dbt package, the Snowflake profile generation macro intentionally always includes private_key and private_key_passphrase parameters regardless of the authentication method. This is a strategic decision to deprecate password authentication and guide all new users toward keypair authentication, even if it means showing keypair parameters when they might not currently be needed.

🔇 Additional comments (2)

macros/edr/system/hooks/on_run_start.sql (2)

2-3: LGTM! Fix correctly addresses the NoneType error.

Initializing the elementary graph unconditionally before the is_elementary_enabled() check ensures the graph object exists even when Elementary is disabled, preventing the 'None' has no attribute 'update' error described in the PR objectives.

---

5-7: LGTM! Proper control flow.

The early return when Elementary is disabled now happens after graph initialization, which is the correct sequence to prevent NoneType errors in downstream code that may reference the graph.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[github-actions]

👋 @yu-iskw
Thank you for raising your pull request.
Please make sure to add tests and document all user-facing changes.
You can do this by editing the docs files in the elementary repository.

[coderabbitai]

Actionable comments posted: 1

📜 Review details

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Disabled knowledge base sources:

• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between 7b5fec6 and 8cf1432.

📒 Files selected for processing (1)

• macros/edr/system/hooks/on_run_start.sql

🧰 Additional context used

🧠 Learnings (1)

📓 Common learnings

Learnt from: arbiv
Repo: elementary-data/dbt-data-reliability PR: 861
File: macros/edr/tests/test_utils/clean_elementary_test_tables.sql:45-50
Timestamp: 2025-09-15T06:06:05.601Z
Learning: In the Elementary dbt-data-reliability codebase, the team prefers simpler, direct approaches over creating helper macros for centralized quoting logic, even when it might provide better maintainability across multiple use cases. They value code simplicity and readability over abstraction.

🔇 Additional comments (1)

macros/edr/system/hooks/on_run_start.sql (1)

2-3: Good fix to prevent NoneType error when Elementary is disabled.

The unconditional initialization before the early return (line 5) ensures the elementary graph object exists even when Elementary is disabled, which resolves the "'None' has no attribute 'update'" error. The init_elementary_graph() macro uses graph.setdefault(), which safely initializes the data structure on first call and is a no-op on subsequent calls, making unconditional initialization both safe and idempotent with no performance overhead.

[yu-iskw]

@MikaKerman Sorry for bothering you, but I appreciate if you could review it.

[arbiv]

@yu-iskw, thanks for your contribution!
I think that a better solution will be not to update the elementary_test_results in case where Elementary is disabled. What do you think?

[yu-iskw]

@arbiv That sounds good. By doing so, we can cut off unnecessary computing resources if Elementary is disabled.

What about implementing that in addition to pull request? I don't think the initialization causes bad side effects. And it can prevent issues like this case, even if we unconsciously change other macros. What do you think?