Skip to content

fix: add explicit return(none) in get_elementary_relation when relation not found#1020

Merged
elazarlachkar merged 1 commit into
masterfrom
devin/1780489496-fix-get-elementary-relation-missing-return
Jun 3, 2026
Merged

fix: add explicit return(none) in get_elementary_relation when relation not found#1020
elazarlachkar merged 1 commit into
masterfrom
devin/1780489496-fix-get-elementary-relation-missing-return

Conversation

@elazarlachkar

@elazarlachkar elazarlachkar commented Jun 3, 2026

Copy link
Copy Markdown
Contributor

Summary

The v0.24.0 refactoring in PR #1006 (deferral fallback) broke get_elementary_relation for environments where elementary tables don't exist and deferral is not active.

Before (v0.23.1): adapter.get_relation() result was always explicitly returned:

{% do return(adapter.get_relation(...)) %}  -- None when table missing

After (v0.24.0): when adapter.get_relation() returns None and deferral is off, the macro falls through without calling return(). In dbt's Jinja2, this returns the rendered template text (whitespace) instead of None. A non-empty whitespace string is truthy, so callers checking {% if relation %} proceed as if the table exists — producing from <whitespace> in SQL, which causes downstream syntax errors like:

Syntax error: Unexpected keyword UNION at [26:17]

Example from Current's environment (does no have a dbt_models table):

image

Fix: add {% do return(none) %} at the end of the macro to restore the v0.23.1 contract.

Related: CORE-930

Link to Devin session: https://app.devin.ai/sessions/1fddd97133934bbd9ab85b4137700ec8
Requested by: @elazarlachkar

Summary by CodeRabbit

  • Bug Fixes
    • Improved consistency in relation handling to ensure predictable behavior when no matching relation is found. This addresses edge cases that could result in unexpected outcomes in certain scenarios.

…on not found

The v0.24.0 refactoring (PR #1006) added a deferral fallback but removed
the unconditional return of adapter.get_relation()'s result. When the
adapter returns None and deferral is off, the macro now falls through
without calling return(). In dbt's Jinja2, this means the macro returns
its rendered template text (whitespace) instead of None. Since a non-empty
string is truthy, callers that check `if relation` incorrectly proceed
as if the table exists, producing SQL like `from <whitespace>` which
causes BigQuery syntax errors.

Add an explicit `return(none)` at the end to restore the v0.23.1
contract: when a relation is not found and deferral is not active,
the macro returns None.

Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
@devin-ai-integration

Copy link
Copy Markdown
Contributor

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

  • Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
  • Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

  • Disable automatic comment, CI, and merge conflict monitoring

@github-actions

github-actions Bot commented Jun 3, 2026

Copy link
Copy Markdown
Contributor

👋 @elazarlachkar
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

coderabbitai Bot commented Jun 3, 2026

Copy link
Copy Markdown

Review Change Stack

📝 Walkthrough

Walkthrough

This PR adds an explicit return(none) statement to the get_elementary_relation dbt macro to ensure deterministic None handling when no matching relation is found and no deferral-based fallback is constructed.

Changes

Deterministic Relation Lookup

Layer / File(s) Summary
Explicit return for relation lookup fallback
macros/utils/graph/get_elementary_relation.sql
An explicit return(none) is added to ensure the macro deterministically returns None when no relation matches and the deferral-based fallback does not trigger.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

Possibly related PRs

  • elementary-data/dbt-data-reliability#1006: Both PRs modify the same macro for relation lookup; PR #1006 adds deferral-aware fallback logic while this PR ensures explicit None return when no relation is found.

Suggested reviewers

  • arbiv

Poem

🐰 When macros return with grace,
Not falling through empty space,
An explicit none, clean and clear,
Makes the intent shine bright here! ✨

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Title check ✅ Passed The title accurately describes the main change: adding an explicit return(none) statement to the get_elementary_relation macro to fix a bug where the macro was falling through without returning None when a relation was not found.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch devin/1780489496-fix-get-elementary-relation-missing-return

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

@elazarlachkar elazarlachkar requested a review from NoyaArie June 3, 2026 12:35
@elazarlachkar elazarlachkar merged commit 1aa94e4 into master Jun 3, 2026
30 of 31 checks passed
@elazarlachkar elazarlachkar deleted the devin/1780489496-fix-get-elementary-relation-missing-return branch June 3, 2026 13:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants