Same ghapi version returns different results depending on fastcore version (JSON `null` → empty `AttrDict`)
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 42/100
Hướng nghiên cứu
Bắt đầu với việc tái hiện GhApi trong issue và so sánh quá trình chuyển đổi phản hồi trên fastcore 1.8.16 và 1.11.2, tập trung vào việc xử lý fastcore.dict2obj được báo cáo. Được xem là hoàn tất khi các giá trị null trong JSON của GitHub luôn giữ nguyên là Python None trên các phiên bản fastcore được hỗ trợ, với hành vi được xác minh thông qua lời gọi liệt kê repository được hiển thị.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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.
- Ngôn ngữ chính
- Python
- Star
- 687
- Fork
- 69
- Merge trung bình
- 1 phút
- Pull request đã merge (30 ngày)
- 2
Hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của AnswerDotAI/ghapi
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
AnswerDotAI/ghapi#158 ·
-
Small fix needed to enable GHES Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
AnswerDotAI/ghapi#120 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 58/100
AnswerDotAI/ghapi#208 ·
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 35/100
AnswerDotAI/ghapi#186 ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 35/100
AnswerDotAI/ghapi#185 · 1 bình luận · 1 reaction ·
Tất cả issue của AnswerDotAI/ghapi
Issue tương tự
-
bug confirmed issue
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
open-webui/open-webui#30750 · 1 bình luận ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
-
enhancement
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
OpenwaterHealth/openmotion-bloodflow-app#604 · 1 bình luận ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
-
good first issue
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 90/100