Same ghapi version returns different results depending on fastcore version (JSON `null` → empty `AttrDict`)
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 42/100
Research direction
Start with the GhApi reproduction in the issue and compare the response conversion under fastcore 1.8.16 and 1.11.2, focusing on the reported fastcore.dict2obj processing. Done means GitHub JSON null values consistently remain Python None across the supported fastcore versions, with the behavior verified through the shown repository-list call.
Written by the indexing model from the issue text.
Description
Summary
When using the same ghapi version, the return value of API calls changes depending on the fastcore dependency version.
Specifically, JSON null values from the GitHub REST API (e.g. repository description) are returned as:
Nonewithfastcore==1.8.16- empty
fastcore.basics.AttrDict({}) withfastcore==1.11.2
This breaks the semantic meaning of the API response and causes downstream issues (e.g. database storage, business logic).
Why this is a problem
- GitHub API explicitly defines
description: nullas “no value” - In Python, this should map to
None {}(empty mapping) has a different semantic meaning thanNone- The behavior changes without changing the ghapi version, only by upgrading a dependency
From a user’s perspective, this means:
The same ghapi version produces different API results depending on dependency resolution
This breaks API contract stability and reproducibility.
Environment
| Component | Version |
|---|---|
| ghapi | 1.0.8 |
| fastcore (local) | 1.8.16 |
| fastcore (sam) | 1.11.2 |
| Python | 3.10.19 |
Reproduction Code
from ghapi.core import GhApi
api = GhApi(token="*******", owner="ORG_NAME")
batch = api.repos.list_for_org("ORG_NAME", per_page=1, page=1)
r0 = batch[0]
print("item:", r0.get("description"), type(r0.get("description")))
print("attr:", r0.description, type(r0.description))
print("has key:", "description" in r0)
Actual Results
With fastcore==1.11.2
item: {} <class 'fastcore.basics.AttrDict'>
attr: {} <class 'fastcore.basics.AttrDict'>
has key: True
With fastcore==1.8.16
item: None <class 'NoneType'>
attr: None <class 'NoneType'>
has key: True
Expected Behavior
JSON null values from the GitHub API should consistently map to Python None, regardless of fastcore version.
At minimum, ghapi should:
- Preserve the semantic meaning of
null - Or pin / constrain fastcore versions to avoid silent behavior changes
Additional Notes
- The conversion appears to happen during
fastcore.dict2objprocessing - ghapi currently forwards this behavior directly to users
- This is not a database or SQLAlchemy issue — the value is already
{}immediately after the ghapi call
This behavior change is unexpected, breaking, and difficult to detect, especially in data ingestion pipelines.
I believe this is worth addressing either in ghapi itself or through tighter fastcore integration.
Thanks for your work on ghapi.
- Dominant language
- Python
- Stars
- 687
- Forks
- 69
- Avg merge
- 1m
- Merged PRs (30d)
- 2
Contributor 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 AnswerDotAI/ghapi
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
AnswerDotAI/ghapi#158 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
AnswerDotAI/ghapi#120 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 58/100
AnswerDotAI/ghapi#208 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 35/100
AnswerDotAI/ghapi#186 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
AnswerDotAI/ghapi#185 · 1 comment · 1 reaction ·
All issues in AnswerDotAI/ghapi
Similar issues
-
bug confirmed issue
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
open-webui/open-webui#30750 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
OpenwaterHealth/openmotion-bloodflow-app#604 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
good first issue
Difficulty 1/5 Under an hour Newbie friendliness 90/100