Based on the knowledge sources, here are some steps and considerations to help diagnose and fix the issue with the dbt_utils.accepted_range test not appearing in your edr report: 1. Check Test Configuration and YAML Sometimes, issues with test configuration in your YAML can prevent results from being stored or displayed. Double-check the YAML for the problematic test and compare it to the working ones. Even small differences (like quoting, indentation, or config blocks) can matter. If possible, try copying the configuration from a working test and adjusting only the column name. 2. Check the

elementary_test_results

Table After running your tests, check if the problematic test appears in the

elementary_test_results

table in your warehouse. If it’s missing, it means the result isn’t being captured by Elementary, which could indicate a configuration or execution issue. If it’s present, but not in the report, the issue may be with how the report is generated or filtered. This step is recommended in several threads as a key diagnostic action [see example](https://slack.com/archives/C02CTC89LAX/p1689364183700999). 3. Run Tests and Report with Consistent Profiles/Targets Ensure that you are running

dbt test

and

edr report

with the same profile and target. Mismatched environments can cause test results to be written to one schema and the report to read from another, resulting in missing data in the UI [see example](https://slack.com/archives/C02CTC89LAX/p1689364183700999). 4. Check for Unique Test IDs If you have changed the column name or test configuration, dbt may treat it as a new test with a new unique ID. Old test results may linger and cause confusion. Make sure you are looking at the latest test run and that there are no stale or conflicting test definitions [see explanation](https://slack.com/archives/C02CTC89LAX/p1668597242823049). 5. Enable Debug Logging You can enable debug logs by adding the following to your `dbt_project.yml`:

yaml    vars:      debug_logs: true

Then, rerun your tests and inspect the logs for any clues, especially around the problematic test. This approach is suggested for deeper troubleshooting [see example](https://slack.com/archives/C02CTC89LAX/p1666679537819579). 6. Check for Sampling/Store Failures For some tests, you may need to set

store_failures: true

to capture failing rows. The behavior of what is stored can differ between dbt native and dbt_utils tests, as noted by a user who observed that dbt_utils tests sometimes return all columns by default, while dbt native tests may not unless configured [see discussion](https://slack.com/archives/C02CTC89LAX/p1710838038179029). If after these steps the issue persists, try isolating the test in question (run only that test) and see if it appears in the results. If not, consider sharing your YAML and logs with the Elementary support team, as they often request these for deeper investigation. Let me know if you need more specific guidance on any of these steps!