The dbt_groups call site of #993 and #994 has no unit backstop — break it and the whole suite stays green
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 72/100
Research direction
Start with TestCompiledEntrypointsAreWiredForTheRightTarget in internal/cli/dbt_projectdir_test.go and its existing dbt: table rows, which go through runDbtCompile (compile.go:180). Add a row with a dag.py plus dbt_groups: config driven through runCompile, so it reaches expandDbtGroupsInFile (compile.go:259). Done when the row asserts the three path shapes and passes, and it fails once !o.build is applied to the group call site.
Written by the indexing model from the issue text.
Description
TestCompiledEntrypointsAreWiredForTheRightTarget (internal/cli/dbt_projectdir_test.go) drives a leoflow.yaml with a top-level dbt: block, so it exercises runDbtCompile (compile.go:180). It never reaches expandDbtGroupsInFile (compile.go:259), which has its own independent dbtProjectDir / dbtProfilesDir pair.
Measured, each break applied alone:
| break | go test ./internal/cli/... |
|---|---|
expandDbtGroupsInFile(..., !o.build) |
ok — full green |
ProfilesDir: removed from the group render |
ok — full green |
So today:
- #994 on the hybrid path is guarded by exactly one thing in the entire repository: assertion A6 in
test/e2e/dbt-mixing-e2e.sh(#1008). A k3d-flaky day silently unguards it. - #993 on the hybrid path is guarded by nothing at all.
The hybrid shape is the authoring mode leoflow targets, so this is the wrong side of the codebase to have uncovered.
The fix
A table row in TestCompiledEntrypointsAreWiredForTheRightTarget driving a dag.py + dbt_groups: config through runCompile, asserting the same three shapes the dbt: rows already assert (image-bound → relative; local → absolute; project with profiles.yml → --profiles-dir).
Strict-TDD order, since the code is currently correct: add the row, watch it pass, apply !o.build to the group call site, watch it fail, revert. ~20 lines.
Found by the review of #1008 — which is why that PR is more load-bearing than its description says.
- Dominant language
- Go
- Stars
- 46
- Forks
- 1
- Avg merge
- 13h 11m
- Merged PRs (30d)
- 684
Getting set up
- Ships a Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from dexadata/dexaflow
-
area/docs documentation priority/p3
Difficulty 1/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
area/ci enhancement priority/p3
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
api: remove dead UI stubs and stale issue references in api_stubs.goPossibly taken @neochaotic claimed this 2 days ago. Openarea/api priority/p3
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 3-5 days Newbie friendliness 62/100
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
Maintainers usually reply within 1 day
All issues in dexadata/dexaflow
Similar issues
-
Headerless responses block while skipping duplicate status linesPossibly taken @mynhe claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 73/100
projectdiscovery/rawhttp#554 ·
-
stage-fail
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
siyuan-note/bazaar#2447 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 80/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
superplanehq/superplane#9120 ·
Maintainers usually reply within 1 day