Loading dictionary without all of the required fields doesn't produce an error in `data_source` function
Maintainers usually reply within 2 days
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 67/100
Research direction
Start by reading the data_source function and trace how it loads the dictionary path provided in the report. Reproduce with a dictionary missing required fields such as $version, tables, and name, then compare the behavior with one validated using the data-dict CLI's validate-spec. Done means invalid dictionaries produce an error or warning instead of loading silently.
Written by the indexing model from the issue text.
Description
What: I manually wrote my data dictionary and omitted several required fields and data_source failed silently/did not produce an error (nor a warning). I figured out that the data dictionary wasn't in the agent context when I was asking the agent about things that it should have had context on from the dictionary. Once I fixed the data dictionary (specifically including $version, tables, name in the dictionary) (I used the data-dict CLI validate-spec to validate the dictionary spec). Then I reloaded the dictionary and it was in the agent's context and answered the questions with that context.
Steps to reproduce the issue:
- An example of the beginning of the data dictionary with the missing required fields (my actual dictionary was much longer)
- provided path to that data dictionary in the dictionary parameter in the
data_sourcefunction (which executes without any errors/warnings).
hikes <- commons::data_source(hikes = hikes_df, dictionary = here::here("dictionaries/hikes_wrong.yaml"))
Environment things for reproducibility:
- R version: 4.6.1
- Rstudio version: 2026.10.0 Build 233
- commons version: 0.1.1
- OS: Windows 11
- Dominant language
- Python
- Stars
- 69
- Forks
- 5
- Avg merge
- 5d 13h
- Merged PRs (30d)
- 30
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
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 posit-dev/commons
-
Difficulty 2/5 1-3 hours Newbie friendliness 80/100
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
Maintainers usually reply within 2 days
-
enhancement py
Difficulty 3/5 1-2 days Newbie friendliness 67/100
Maintainers usually reply within 2 days
-
py
Difficulty 4/5 1-2 days Newbie friendliness 35/100
posit-dev/commons#471 · 1 comment ·
Maintainers usually reply within 2 days
-
include `instructions` in the commons' print method outputPossibly taken @simonpcouch claimed this 3 days ago. Open
Difficulty 3/5 Half a day Newbie friendliness 25/100
Maintainers usually reply within 2 days
All issues in posit-dev/commons
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
didi/helixharness#18 ·
-
request-theme
Difficulty 1/5 Under an hour Newbie friendliness 78/100
LizardByte/ThemerrDB#9883 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
NousResearch/hermes-agent#149885 ·
Maintainers usually reply within 1 day
-
Set cache_ok = True on GUID TypeDecorator to enable SQLAlchemy query cachingPossibly taken @patelshivani2283-lab claimed this today. Open
Difficulty 1/5 Under an hour Newbie friendliness 91/100
fedora-infra/anitya#2157 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Project-MONAI/MONAI#9258 ·
Maintainers usually reply within 3 days